OS/2, eCS & ArcaOS - Technical > Applications

Creating some apps RPM packages

<< < (2/14) > >>

Andreas Schnellbacher:
The link seems to work from (now?) Germany.

Martin, thanks for this.

BTW: I don't see the sense of moving more files than necessary to the UNIXROOT tree, but I'm an early endorser of that concept. Details:

IMO it makes sense to put files of ported Linux tools used by other ported ones to the UNIXROOT tree. The amount of files therein is already complex.

I don't get why to put e.g. assoedit files there. What we need is an additional common place, at least for executable and DLL files. That one should be provided by the OS and its subpaths should be added to the relevant paths in CONFIG.SYS.  It would make installation of tools that are used from the command line much easier. GUI ones usually don't need that. See WarpIN as an example. My suggestion is:

This entry in CONFIG.SYS already exists:
   SET PROGRAMS=x:\Programs
These subdirs have to be created and added to SET PATH, LIBPATH, SET HELP, SET BOOKSHELF in CONFIG.SYS (with %PROGRAMS% expanded):
   %PROGRAMS%\bin, %PROGRAMS%\dll, %PROGRAMS%\help, %PROGRAMS%\book

(While I would prefer the shorter term SET PROGRAMS=x:\Apps, but that's my personal taste.)

Non-command-line tools could be installed in one or a few subdir(s) below %PROGRAMS% or anywhere else, as they don't need common paths.

Dave Yeo:
The drawback is that PATH, LIBPATH etc are finite resources. They are limited in length and the longer they are, the more time to search them.
With a package manager, they can all be put into the same directory structure and the package manager can take care of keeping track.
Another option is to have cmd files that set the environment for the programs installed under x:\programs and a common bin file where the cmd files go.

Andreas Schnellbacher:

--- Quote from: Dave Yeo on February 14, 2021, 07:03:28 pm ---The drawback is that PATH, LIBPATH etc are finite resources. They are limited in length and the longer they are, the more time to search them.

--- End quote ---
Good point. That's the reason why I vote for a just few common paths. And GUI apps usually don't need these paths. But BTW: The search time doesn't matter nowadays.


--- Quote from: Dave Yeo on February 14, 2021, 07:03:28 pm ---With a package manager, they can all be put into the same directory structure and the package manager can take care of keeping track.

--- End quote ---
Sure, but why under UNIXROOT? Packages may be installed anywhere. A package manager is also able to install system (IBM) files. Placing more files than required under UNIXROOT makes the emergency method to fix a broken RPM tree more complicated: Wipe and recreate it. (I had to do that 2 times, probably due to bugs in packages installation scripts.)


--- Quote from: Dave Yeo on February 14, 2021, 07:03:28 pm ---Another option is to have cmd files that set the environment for the programs installed under x:\programs and a common bin file where the cmd files go.

--- End quote ---
I guess most of the time GUI apps are started via program objects, not via paths. Then you don't need a fixed path for executing them. But it's useful for installers or package managers to know the default destination for installation. Setting the env. via .cmd file is the usual method for developers. But for others?

WarpIN is a very good example: Ulrich decided to avoid PATH cluttering. The GUI program doesn't need a fixed path. For wic.exe, he povided a .cmd script that sets the env. locally to find its DLL. That way WarpIN can reside in its own directory anywhere. The path is written to OS2.INI, but nothing more. (I would rather count WarpIN as a system tool than AssoEdit.)

Next example is 4OS2: Should it be added to an own directory or to a common directory tree? The standard way is to install it in its own dir and append that to PATH, LIBPATH, DPATH, HELP and BOOKSHELF. I would prefer common paths instead that are already added to these paths.

Martin Iturbide:
Hi Andreas

This are the "path definitions" that can became an issue while creating RPM packages. I''m not a fan of the FHS, but it is what I have here.
 

--- Quote from: Andreas Schnellbacher on February 14, 2021, 06:21:51 pm ---BTW: I don't see the sense of moving more files than necessary to the UNIXROOT tree, but I'm an early endorser of that concept. Details:

--- End quote ---

Do you have experience with RPM packages? For the moment I don't know how to install things outside the UNIXROOT, if you have some samples let me know, I had a lot of issues understanding the %files section of the specs files.

Regards

Dave Yeo:
How about having a directory under @unixroot\share? Perhaps @unixroot\share\os2_apps or such.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version