I have them here for the moment: https://archive.org/download/rpm-warp-samples (https://archive.org/download/rpm-warp-samples)
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.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.
With a package manager, they can all be put into the same directory structure and the package manager can take care of keeping track.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.)
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.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?
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:
This are the "path definitions" that can became an issue while creating RPM packages.I see. If that's really true, we should better avoid it for non-ported OS/2 apps, IMO.
Do you have experience with RPM packages?No.
In RPM How-To document for packagers (http://trac.netlabs.org/rpm/wiki/RpmHowToPackagers#Filepackaging) there is:This are the "path definitions" that can became an issue while creating RPM packages.I see.
%files
%{_bindir}/rpm.exe
%{_mandir}/man8/rpm.8*
%{_libdir}/rpm*.dll
It looks to me as if any path or env var can be used here.
This is an issue for me, since I need to take out the "C:" for the cp command to work. If I can only know how to trim the first to characters, it will be fine for me.
echo %PROGRAMS% | cut -c 3-
[C:\]echo %PROGRAMS%
F:\Apps
[C:\]sh
#
# rpm --eval %{echo:$PROGRAMS\\myapp}
F:\Apps\myapp
# exit
[C:\]rpm --eval %{echo:$PROGRAMS\\myapp}
$PROGRAMS\\myapp
%_programs %{echo:PROGRAMS}
...
%{_programs}/...
or
%{_programs}\\...
- always use the '.oc00' distribution identifierI have no idea what is this '.oc00'. I don't know where it came from, on the specs it came from "{?dist}"
I would love the see the specs samples that you have produced for the OS2VOICE RPM.
I would also like to check your suggested specs for "legacy software".
Are you writing the os2voice rpm rules somewhere?
I will like to collaborate creating more packages.
I have no idea what is this '.oc00'.
I don't know where it came from, on the specs it came from "{?dist}"
# System-wide path for OS/2 language files accessed via DPATH env. variable.
%os2_langdir %{_datadir}/os2/lang
# System-wide path for OS/2 INF files accessible via BOOKSHELF env. variable.
%os2_bookdir %{_datadir}/os2/book
# System-wide path for OS/2 HLP files accessible via HELP env. variable.
%os2_helpdir %{_datadir}/os2/help
those values are defined in rpm anyway. So don't add new stuff to dpath, help env and so forth
every installation has those values defined.
# rpm --eval %{_programs}
%{_programs}
# rpm --eval %os2_langdir
/@unixroot/usr/share/os2/lang
# rpm --eval %os2_bookdir
/@unixroot/usr/share/os2/book
# rpm --eval %os2_helpdir
/@unixroot/usr/share/os2/help
#
I want to find a way to install things on the \Programs\ path without hard coding it.
/@unixroot/var/programs/MyLegacyApplication
Those are "path choices" I was talking about on the first post :DIndeed.
Is really "/@unixroot/var/programs/MyLegacyApplication" a good place for this "legacy OS/2 application" ?No it is not.
FC2_README:WPProgram|File Commander/2 Read Me|<FC2_FOLDER>|EXENAME=e.exe;\PROGTYPE=PROG_PM;PARAMETERS=((%doc/fc.txt));OPEN=RUNNING
# Converts back slashes to forward slashes.
%os2_fwdslashes()
# Converts forward lashes to back slashes.
%os2_backslashes()
FC2_README:WPProgram|File Commander/2 Read Me|<FC2_FOLDER>|EXENAME=e.exe;\PROGTYPE=PROG_PM;PARAMETERS=((%doc/fc.txt));OPEN=RUNNING
Please note that File Commander (http://silk.apana.org.au/fc.html) is not freeware.
QuoteFC2_README:WPProgram|File Commander/2 Read Me|<FC2_FOLDER>|EXENAME=e.exe;\PROGTYPE=PROG_PM;PARAMETERS=((%doc/fc.txt));OPEN=RUNNING
Wat is that backslash before PROGTYPE doing there ?
It is also in your 'Larsen_Commander.spec' file from your posted examples.
uhm... I'm still do not know if I'm using the %doc correctly. I'm putting almost all readme.txt files, like history.txt, whatsnew.txt, and all alike inside that directoy that at the end is "usr/share/doc/-name of the app-version/"
FWIW:
%doc is used to mark files as documentation.
It has to do with RPM querying -- querying a list of documentation files.
The files themselves still must be part of the %files section.
See: File-related Directives (http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html)
But if it is a .txt used by the application, like "high score" for a game or anything like that I'm putting it on "usr/share/-name of the app/".
Engineering | Development (http://devel.os2voice.org) |
Collaboration | Working Together (http://collab.os2voice.org) |
Provisioning | Providing Packaged Software (http://rpm.os2voice.org) |
I have never understood the reason for using RPM/YUM as an installer in OS/2/ArcaOS.
We have a very good installer in WARPIN, it can find where older versions of programs are, make new directories and add them to the LIBPATH and PATH and so on. I assume it was discarded because some people thought writing the install script was too much effort when they could dump everything in the same directory - not a good idea.
I too do not update my install unless it is something I can download and install myself.
although it needs a better database for storing installed app information; the 2 levels that INI files provides is not enough.
What Martin was talking about was RPM-izing legacy type OS/2 apps.
That means I really need to keep my boot drive partitioned at 2 GB or less and I need to be careful about what I install on the boot drive so I don't run out of space.
The downside of RPM verses WarpIn is it looks like RPM is much more complicated to setup. I mean complicated for the app maker to setup an install to work with RPM.
The problem with using a database that only has 2 levels to track installed products (like WarpIn) is if the product has lots of components the "application" is listed multiple times with different "keys" in order to list the different components or subsystems. If you want to deinstall the product you have to deinstall each of the application-key pairs. To use an example: Doodle's Screen Saver is listed as an application 29 times (on my machine) in WarpIn's database. So to deinstall one has to right-click 29 times on the application and select deinstall.
But the issue is why should I have to? When the better way is to simply give the user the choice on where to install a product when using APM/YUM/RPM.
When the better way is to simply give the user the choice on where to install a product when using APM/YUM/RPM.
I think Martin IS intending to distribute old style OS/2 apps that way. And I think it is an excellent idea if we can get some flexibility in the install process.
I am just trying to, politely, suggest that adding the ability to select a destination for a application when installing with APM/YUM/RPM would be a fantastic feature.
What Martin was talking about was RPM-izing legacy type OS/2 apps. That has lots of benefits, and some downsides.
But I still haven't full started with the RPM installers. On my last attempts I got stuck with the WPS integration to create icons and set the properties of WPS objects (Path, working directory, etc). I usually get the answer that it works, but I'm doing it wrong, but nobody tells me how to do it right.
But I still haven't full started with the RPM installers. On my last attempts I got stuck with the WPS integration to create icons and set the properties of WPS objects (Path, working directory, etc). I usually get the answer that it works, but I'm doing it wrong, but nobody tells me how to do it right.
I do this using REXX scripts. This is called from the %post section of the .spec file for installation and from the %postun section for uninstallation. My restartwps.exe utility is also used to restart the desktop correctly.
My .spec:
ftp://os2.snc.ru/pub/freerdp/RPM/ofreerdp.spec (ftp://os2.snc.ru/pub/freerdp/RPM/ofreerdp.spec)
REXX scripts and restartwps.exe:
ftp://os2.snc.ru/pub/freerdp/RPM/spec-tools/ (ftp://os2.snc.ru/pub/freerdp/RPM/spec-tools/)
(see "restartwps.exe -?" for help)