Author Topic: Discussion about RPM/YUM and Libcn  (Read 26506 times)

Jochen Schäfer

  • Sr. Member
  • ****
  • Posts: 306
  • Karma: +27/-0
    • View Profile
Re: Discussion about RPM/YUM and Libcn
« Reply #15 on: May 08, 2019, 11:14:18 pm »
Again, LIBCN works on most OS/2 versions, AFAIK. So DOSBOX will work with it.If I use LIBCN, I will include it.
So, please stop your crusade in this thread, because it's not approbiate in the case of DOSBOX.
Or, do you know breaking changes happening in LIBCN?

The problem with including any version of libc, including LIBCN is that in a year, after LIBCN has been updated, a user might download your package and downgrade LIBCN and break other packages that depend on new functionality.
Yes, but the DLLs are installed in DOSBOX's directory. DLL hell, I know, but at least nothing gets mixed up.


Andreas Schnellbacher

  • Hero Member
  • *****
  • Posts: 827
  • Karma: +14/-0
    • View Profile
Re: Discussion about RPM/YUM and Libcn
« Reply #16 on: May 09, 2019, 01:46:16 am »
The converse is also possible with the newer version breaking older programs - yes I know that those producing the new version can't test it against every program that uses it.  That is why I have always tried to put everything a program needs to run in the directory of the program  and run everything from there.
That would increase the limitation caused by short shared memory extremely. It isn't a good idea, IMO.

A package writer can handle the problem better then simply adding DLLs that may be already installed by other packages: He can make the installation (addition) of these files optional and add code to preselect the proper selection state for it. For most users, the preselection is important, IMO. That's convenient for non-RPM users.

For an RPM user, it's important that a check for missing dependent packages is made before the preselection. Otherwise he may unintentionally end with a system having both local and common system DLLs, if system DLLs are included. In case anything misses, it should either be installed optionally or at least a message should pop up how the dependent packages have to be added (a yum or ANPM line).

IMO, it's better to assume the RPM method is used for installing system files. Additional dependent system DLLs should better be distributed in another package, if at all, for non-RPM users.

Both methods are possible with WarpIN, but one needs quite some code. Additionally, the next ANPM versions could handle the case when system DLLs were already installed by WarpIN packages. Much depends on how thoroughly the package writer has worked.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: Discussion about RPM/YUM and Libcn
« Reply #17 on: May 09, 2019, 02:19:23 am »
Quote
It isn't a good idea, IMO.

It is definitely a very BAD idea, IMO. If a package is to include DLLs, they should have unique names, and never duplicate what is in RPM/YUM.

Quote
That's convenient for non-RPM users.

I don't know about others who package programs, but after spending a lot of hours trying to figure out how to do that with Firefox (a few years ago), I came to the conclusion that I have better things to do with my life. If a user insists on doing that manually, they can do the work to figure it out. I can usually install all listed packages in a couple of minutes, using ANPM (Arca Noae package manager), and it gets done right. At the time, there were a few people who spent days trying to get things right, for Firefox. Most packagers just don't have the time to do that, and I hate to see programmers wasting their time doing it. It should be sufficient for them to list the required packages, and let ANPM (RPM/YUM) figure it out for the users.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4775
  • Karma: +99/-1
    • View Profile
Re: Discussion about RPM/YUM and Libcn
« Reply #18 on: May 09, 2019, 02:58:45 am »
Again, LIBCN works on most OS/2 versions, AFAIK. So DOSBOX will work with it.If I use LIBCN, I will include it.
So, please stop your crusade in this thread, because it's not approbiate in the case of DOSBOX.
Or, do you know breaking changes happening in LIBCN?

The problem with including any version of libc, including LIBCN is that in a year, after LIBCN has been updated, a user might download your package and downgrade LIBCN and break other packages that depend on new functionality.
Yes, but the DLLs are installed in DOSBOX's directory. DLL hell, I know, but at least nothing gets mixed up.

And, for example, they start Dosbox first, which loads the old libc and then starts something else that needs a newer one and the other program won't run, the user will be left scratching their head, not understanding that Dosbox loaded the wrong libc into memory and other programs are using that version.
Libc is as much a system dll as anything and just like other system dlls such as PMMERGE, shouldn't be included in your program.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4775
  • Karma: +99/-1
    • View Profile
Re: Discussion about RPM/YUM and Libcn
« Reply #19 on: May 09, 2019, 03:07:33 am »
Hi Dave,
Quote
The problem with including any version of libc, including LIBCN is that in a year, after LIBCN has been updated, a user might download your package and downgrade LIBCN and break other packages that depend on new functionality

The converse is also possible with the newer version breaking older programs - yes I know that those producing the new version can't test it against every program that uses it.  That is why I have always tried to put everything a program needs to run in the directory of the program  and run everything from there.

One possible workround would be to go the whole hog and use a program that makes a snapshot of the OS just as they do in Linux Mint, then if anything goes wrong everything can be restored to the previous working state.

Libc is one library where backwards compatibility should always be expected, and gets tested when in the experimental repository. If backwards compatibility is broken, the version will be changed.
It is easy to take a snapshot like Mint does if you choose, it just uses rsync.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4775
  • Karma: +99/-1
    • View Profile
Re: Discussion about RPM/YUM and Libcn
« Reply #20 on: May 09, 2019, 05:23:16 am »
Another option if you insist on adding libc etc is to enforce BEGINLIBPATH and LIBPATHSTRICT so the ones that come with DOSBOX are used only by DOSBOX. Something like
Code: [Select]
/* Add directory where EXE is located to LIBPATH */
/* And set LIBPATHSTRICT */
DosSetExtLIBPATH((PCSZ) basepath, BEGIN_LIBPATH);
DosSetExtLIBPATH((PCSZ)"T", LIBPATHSTRICT);
basepath could even be .\.

Jochen Schäfer

  • Sr. Member
  • ****
  • Posts: 306
  • Karma: +27/-0
    • View Profile
Re: Discussion about RPM/YUM and Libcn
« Reply #21 on: May 09, 2019, 11:19:06 am »
1.) The DLLs are their own package and don't need to be installed. @Andreas, how can I switch the default state of a package. Honestly, 15 years ago, when starting porting and maintaining DOSBOX, somebody write me the Warpin scripts.

2.) @Dave: Good hint. I will try to insert that in the next release.

EDIT:
3.) I really would to also build an RPM version, but I can't even get the SDL extension to build, because dynamic build seems to be impossible.

I'm open to suggestion about how to make the package better and more reliable. I'm just not familiar with every OS/2 intricacy, as I'm only use it to build DOSBOX.
« Last Edit: May 09, 2019, 11:21:56 am by Jochen Schäfer »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4775
  • Karma: +99/-1
    • View Profile
Re: Discussion about RPM/YUM and Libcn
« Reply #22 on: May 09, 2019, 04:35:34 pm »
EDIT:
3.) I really would to also build an RPM version, but I can't even get the SDL extension to build, because dynamic build seems to be impossible.

I'm open to suggestion about how to make the package better and more reliable. I'm just not familiar with every OS/2 intricacy, as I'm only use it to build DOSBOX.

How are you building Dosbox, GCC or OpenWatcom? And likewise with the SDL libraries?

Andreas Schnellbacher

  • Hero Member
  • *****
  • Posts: 827
  • Karma: +14/-0
    • View Profile
Re: Discussion about RPM/YUM and Libcn
« Reply #23 on: May 09, 2019, 10:41:34 pm »
@Andreas, how can I switch the default state of a package.
It's no problem to give examples. (NEPMD, my project, is one.) But from what you wrote after that, it seems that you rather need other support for that.

Honestly, 15 years ago, when starting porting and maintaining DOSBOX, somebody write me the Warpin scripts.
I don't remember how Dosbox is distributed. My first thought today: If I'll find time I'll enhance the WarpIN installation. Bur after having read what I wrote last night and what others wrote about system DLLs, my opinion has changed a bit:

In NEPMD, I've included 1) md5.exe by Bob Eager, 2) lxlite.exe and unlock.exe and 3) wptools.dll. These are must-have tools to allow NEPMD process basic functions.

To 1) md5sum is nowadays installed on modern systems. md5.exe is then deactivated on installation. But unfortunately an already installed md5.exe NEPMD tool is not automatically uninstalled if md5sum.exe was found in the meantime. Md5.exe itself hasn't changed in the past and because it's an EXE and not a DLL, it won't interfere with other apps. Therefore: No problem to provide md5.exe with NEPMD. I've left it in the NEPMD package, because it was included already before the RPM/YUM times. The same applies to both other tools.

To 2) lxlite.exe and unlock.exe are system tools since an eCS version. They haven't changed much in the past. bww has released a new version with included changes from various people. I had replaced the previous Hobbes files with the bww files in the NEPMD package. Again, these files are EXEs, so it's no problem for other apps. There were installed in a tools dir that is not included in NEPMD's extended PATH. That means that also from command line, ther's no danger with these files.

To 3) wptools.dll is included since an eCS version. Even being a DLL, distributing it maybe additionally with a package may cause no problems, because development has stopped and it hasn't changed since ages.

But I won't include any of the e.g. gcc* DLLs with NEPMD, because such files are maintained and changed often.

So in your case, I find it the best method to avoid inclusion of these files. That applies also to libcn. If you want to support people who defer to use RPM/YUM, I see it as the only option to provide the required files in a separate package. (Steve Wendt did that for Mozilla versions.) With "package" I mean also "file". That means: create a special .wpi with these DLLs, but better keep them quite hidden to ensure people don't install them by mistake.

Dave has already described what the biggest problem for other apps may be. So, easiest is to just refer to the "yum install" command to install the prerequisites. What WarpIN can do, is to check for prerequisites and defer installation without it. Let's see, if I find time during the weekend to give examples and to add that to the Dosbox .wis script.
« Last Edit: May 09, 2019, 10:53:17 pm by Andreas Schnellbacher »

Jochen Schäfer

  • Sr. Member
  • ****
  • Posts: 306
  • Karma: +27/-0
    • View Profile
Re: Discussion about RPM/YUM and Libcn
« Reply #24 on: May 09, 2019, 11:24:11 pm »
How are you building Dosbox, GCC or OpenWatcom? And likewise with the SDL libraries?
GCC 4, SDL from RPM.
I have to built the SDL dependencies like Ogg, SDL_net statically. I'm not able to build DLLs from them.

Jochen Schäfer

  • Sr. Member
  • ****
  • Posts: 306
  • Karma: +27/-0
    • View Profile
Re: Discussion about RPM/YUM and Libcn
« Reply #25 on: May 09, 2019, 11:31:33 pm »
I find it the best method to avoid inclusion of these files. That applies also to libcn. If you want to support people who defer to use RPM/YUM, I see it as the only option to provide the required files in a separate package. (Steve Wendt did that for Mozilla versions.) With "package" I mean also "file". That means: create a special .wpi with these DLLs, but better keep them quite hidden to ensure people don't install them by mistake.

Dave has already described what the biggest problem for other apps may be. So, easiest is to just refer to the "yum install" command to install the prerequisites. What WarpIN can do, is to check for prerequisites and defer installation without it. Let's see, if I find time during the weekend to give examples and to add that to the Dosbox .wis script.
Very helpful remarks. Since 15 years, I on and off release some Warpin packages for DOSBOX. Nobody ever complained about how I package it or suggested how to do it better.
Thank you Andreas and Dave.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4775
  • Karma: +99/-1
    • View Profile
Re: Discussion about RPM/YUM and Libcn
« Reply #26 on: May 10, 2019, 02:41:40 am »
How are you building Dosbox, GCC or OpenWatcom? And likewise with the SDL libraries?
GCC 4, SDL from RPM.
I have to built the SDL dependencies like Ogg, SDL_net statically. I'm not able to build DLLs from them.

Why not use the RPM version of libogg? SDL_net.dll (or sdlnet.dll) should be easy to build, though by going static, you do avoid DLL hell.

Jochen Schäfer

  • Sr. Member
  • ****
  • Posts: 306
  • Karma: +27/-0
    • View Profile
Re: Discussion about RPM/YUM and Libcn
« Reply #27 on: May 10, 2019, 08:31:32 am »
I don't know anymore. Perhaps it was the DOSBOX configure script acting up.
In the end, it comes down to me wanting to produce the RPM packages for the dependencies, but not being able to.
I wanted to look into the SDL source package, anyway. Perhaps there I can unearth something.

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4696
  • Karma: +41/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: Discussion about RPM/YUM and Libcn
« Reply #28 on: May 10, 2019, 01:57:21 pm »
Hi

I have some issues with the SDL 1.2x on the rpm package with some SDL ported games I'm trying.
1) There is the confusion between sdl and SDL on the repository.
2) It seems that some DLLs are missing like the mixer, image, net, sound on the rpm package. Checking the contents of the SDL and sdl packages does not list those.

This is why I had skipped the SDL (and sdl) package from the rpm repo and started using the ones on hobbes (SDL-1.2.15-20160303.zip and SDL2-2.0.4-20160225.zip) for trying the game SDL apps.

As a convenience I would like to have a full SDL1 and SDL2 DLL's on the rpm repository and I will like to have DOSBox/2 also installable from rpm. Like I said before on this forum, I dislike FHS and using rpm/yum from command line, but since we have ANPM, I was able to tolerate it.  But it is just my personal opinion.

Regards
Martin Iturbide
OS2World NewsMaster
... just share the dream.

Doug Clark

  • Sr. Member
  • ****
  • Posts: 306
  • Karma: +7/-1
    • View Profile
Re: Discussion about RPM/YUM and Libcn
« Reply #29 on: May 11, 2019, 07:38:11 am »
My 2 cents for what it is worth:

1) I think Arca Noae is doing a great job. They may not have delivered everything that was promised, but I am amazed at what they WERE able to accomplish; things that I thought would never happen. Such as getting SNAP to work with multiprocessor systems. The fact that Arca packages stuff together (even if it is stuff that is available separately,) and tests it, is worth alot to me. Easily worth the money they charge. Just my opinion.

2) I don't much like the unix-ifying of OS/2 that is happening, but at the same time recognize that is where the new applications are coming from. I will swallow my dislike for unix type structure and conventions in order to get the progress that happens from porting stuff from Linux to OS/2.

3) I have gone from despising YUM/RPM/APM to actually liking RPM. Sort of. As others have discovered, it is almost impossible to keep track of the zillions of DLLs that are used in the various Linux ports, and that seem to change every thirty minutes or so,  without RPM. And it is nice to be able to go to one spot, APM, and update libraries and packages.

4) It seems to me that what we need is for WarpIn and RPM to be able to share (or at least read) the same database, so that each could track what was installed by the other. I don't know what type of database RPM uses, but I do know that the 2-level structure of OS/2 .INI files WarpIN uses is really not sufficient to keep track of applications of any size, so WarpIn really needs a database upgrade anyway.

5) Changes are getting made to basic parts of the LIBC/EMX components that break older applications. XFree86 is an example. So having a "snap shot" of the DLLs used by an application is really necessary now, and will be in the future, for applications to continue running while all the infrastructure is updated. For XFree86 I installed it on a virgin ECS system, zipped up the X11, USR, VAR directory trees and moved the whole thing to AOS in its own location. I believe Dave pointed out the problems with doing that, but I don't see an alternative. So maybe the solution to so put all the packages in RPM, but also provide a zipped copy of the files needed - as installed -  so that  in the future when the "standard" RPM distribution changes enough to break the application, someone can create a separate directory structure with what is needed for that application.