OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Applications => Topic started by: Martin Iturbide on February 13, 2021, 05:07:12 pm

Title: Creating some apps RPM packages
Post by: Martin Iturbide on February 13, 2021, 05:07:12 pm
Hi

I had been creating some simple rpm packages for some OS/2 utilities that we discussed on the forum.  The idea for me is to have, eventually, a very simple and fast to install the tools that are commonly used in ArcaOS.

By learning how to make that packages, I checked other samples, and there some choices that sometimes had to be done in file locations (because of the FHS thing) like:
- Where to put HLP files ? - I choose "/@unixroot/usr/share/os2/help"
- Where to put the TXT files? - I choose "@unixroot/usr/share/doc/%{name}"
This was based on some other samples I checked.

I have them here for the moment: https://archive.org/download/rpm-warp-samples (https://archive.org/download/rpm-warp-samples)

Those are far from perfect, but I hope someday they can be improved and put no some RPM server.

Suggestions are always welcome.

Regards

Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on February 14, 2021, 01:12:23 am
Hi

Just in case to install those manually you can try:
 "yum install <full file name.rpm>"

Or from ANPM:
 Manage->YUM Tools->"Install Package from file..."

This are the package I created:

- AssoEdit-2.1.2-1.oc00.i686.rpm
- CleanINI-0.55-1.oc00.i686.rpm
- Diunpack-3.04B-1.oc00.i686.rpm
- KillFold-1.0-1.oc00.i686.rpm
- LX2Dump-1.03-1.oc00.i686.rpm
-  Larsen_Commander-1.6_M3-1.oc00.i686.rpm
- PMDLL-2.12-1.oc00.i686.rpm (not much needed since it is included on ArcaOS)
- PMDiff-4.0c-1.oc00.i686.rpm
- PMKill-1.0-1.oc00.i686.rpm
- ToLower-1.1-1.oc00.i686.rpm
- VisPro-REXX-Runtime-3.1-1.oc00.i686.rpm
- WatchDog-1.0-1.oc00.i686.rpm
- ePDF-2.99-1.oc00.i686.rpm

Regards
Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on February 14, 2021, 01:50:51 pm
I included:
- TaskBuster-2.00-1.oc00.i686.rpm
- WinBack-2.0-1.oc00.i686.rpm
Title: Re: Creating some apps RPM packages
Post by: Mike Kölling on February 14, 2021, 02:17:06 pm

I have them here for the moment: https://archive.org/download/rpm-warp-samples (https://archive.org/download/rpm-warp-samples)


Hi Martin,

Thanks for all your efforts. I lie the idea for the rpm packages.
Is there a way to download these files? The link provided does not work.

Grettings,
Mike
Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on February 14, 2021, 05:45:38 pm
Hi Mike

Can you check if you can access archive.org? I remember that some countries (or ISPs) blocked it. If so, you may need a proxy.

Regards
Title: Re: Creating some apps RPM packages
Post by: Andreas Schnellbacher on February 14, 2021, 06:21:51 pm
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.
Title: Re: Creating some apps RPM packages
Post by: 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.
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.
Title: Re: Creating some apps RPM packages
Post by: Andreas Schnellbacher on February 14, 2021, 07:57:57 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.
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?

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.
Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on February 14, 2021, 11:15:57 pm
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.
 
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:

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

Title: Re: Creating some apps RPM packages
Post by: Dave Yeo on February 15, 2021, 01:08:03 am
How about having a directory under @unixroot\share? Perhaps @unixroot\share\os2_apps or such.
Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on February 15, 2021, 01:39:33 am
Hi

Those are the choices that had to be done.

For example, I just made (and uploaded) the "FileFreedom" RPM installer.
- C:\USR\BIN\FILEFRDM.EXE  -- The binary
- C:\USR\SHARE\OS2\HELP\filefrdm.hlp   -- The Help File (I also included this path on the SET HELP=)
- C:\USR\DOC\FILEFREEDOM\*.TXT -- The readme files.
-- Executable Working Directory on C:\HOME\.CONFIG\FILEFREEDOM\  -- So the .INI file get stored there.

I know this is too much trouble, but this is how I see things are organized with the FHS hell.

Regards
Title: Re: Creating some apps RPM packages
Post by: Andreas Schnellbacher on February 15, 2021, 09:43:29 am
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.
Title: Re: Creating some apps RPM packages
Post by: Andreas Schnellbacher on February 15, 2021, 10:29:38 am
This are the "path definitions" that can became an issue while creating RPM packages.
I see.
In RPM How-To document for packagers (http://trac.netlabs.org/rpm/wiki/RpmHowToPackagers#Filepackaging) there is:
Code: [Select]
%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.
Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on February 15, 2021, 01:59:46 pm
Hi

If I use %PROGRAMS% directly on the specs file it does not work (it created a directory called "%PROGRAMS%")

I need a way to get the variable for "C:\PROGRAMS", if I hardcode the path it will work, but I would like to get some kind of variable like "%{_programs}" (which does not work), or any variable that will work to get me the "PROGRAMS" path.

Any tips are welcome.

Regards

Title: Re: Creating some apps RPM packages
Post by: Andreas Schnellbacher on February 15, 2021, 06:52:56 pm
I don't know where %{_programs} should stay for, but I would try it with %{PROGRAMS}.
Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on February 16, 2021, 05:14:51 am
Hi

%{PROGRAMS} didn't work to create the RPM packaged.  :(

Regards
Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on February 16, 2021, 02:04:26 pm
Hi

I'm trying  "%{getenv:PROGRAMS}"  but it gets me "C:PROGRAMS" without the backslash.

- %{getenv:PROGRAMS} = C:PROGRAMS
-  %{getenv:HOME}   =  C:HOME

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.

Regards
Title: Re: Creating some apps RPM packages
Post by: Dave Yeo on February 16, 2021, 04:33:12 pm
The backslash is an escape character on *nix and needs escaping. Try "SET PROGRAMS=c:\\programs"
Title: Re: Creating some apps RPM packages
Post by: Dave Yeo on February 16, 2021, 04:55:10 pm
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.

Code: [Select]
echo %PROGRAMS% | cut -c 3-



Title: Re: Creating some apps RPM packages
Post by: Andreas Schnellbacher on February 16, 2021, 06:51:32 pm
I've tried and read a bit, but haven't tried to build an .rpm. I'm still not sure if rpm uses the sh or the cmd syntax. Here's what I got:
Code: [Select]
[C:\]echo %PROGRAMS%
F:\Apps

[C:\]sh
#

# rpm --eval %{echo:$PROGRAMS\\myapp}
F:\Apps\myapp

# exit

[C:\]rpm --eval %{echo:$PROGRAMS\\myapp}
$PROGRAMS\\myapp

I've found that expressions beginning with "${_" are macros. According to this, defining the macro in the header and using it below might work:
Code: [Select]
%_programs %{echo:PROGRAMS}
...
%{_programs}/...
or
%{_programs}\\...
Title: Re: Creating some apps RPM packages
Post by: Ben Rietbroek on February 17, 2021, 04:06:32 pm
Hi,

My name is Ben Rietbroek and I am working on RPM for V.O.I.C.E
(VOICE Software Provisioning)

The use of RPM packages for OS/2 will increase in the future, so it might be
a good idea to think about conventions all RPM providers should adhere to.

These are the conventions I settled on for VOICE:
- package names are lowercase
- the dash (-) is used to separate name components
- no underscores (_)
- always use the '.oc00' distribution identifier

I am developing automated RPM stuff so consistent naming is important for
proper processing.

Additionally one can distinguish between packaging legacy software and
*NIX ported software. This has to do with the locations where the files are
installed and their structure.

And there are more things which would need some cooperation among
package providers so we do not make a mess of our upcoming repositories.

I am open for discussion on these subjects, either at this forum or via:
ben-at-rpm.os2voice.org

Best regards,
Ben Rietbroek.
(aka rousseau)
Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on February 18, 2021, 02:00:33 am
Hi Ben

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.

- always use the '.oc00' distribution identifier
I have no idea what is this '.oc00'. I don't know where it came from, on the specs it came from "{?dist}"

Regards
Title: Re: Creating some apps RPM packages
Post by: Ben Rietbroek on February 19, 2021, 06:34:22 pm
Hi Martin,

Quote
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".

I will address the above with a broader document in a Request-For-Comments (RFC)
fashion. I am working on that.

Quote
Are you writing the os2voice rpm rules somewhere?

I am writing almost everything down, from issues with tools to useful conventions to
ideas that popup in my head. They all have a tag and there is a background task active
clustering relevant stuff to produce a coherent document.

Quote
I will like to collaborate creating more packages.

That is very cool.
I tool the liberty to send you an invitation to become a "bollplanker", which kinda means this
https://en.wiktionary.org/wiki/bollplank
and where the focus is on _your_ perspective of things.

Quote
I have no idea what is this '.oc00'.
I don't know where it came from, on the specs it came from "{?dist}"

It is defined in: '@unixroot/etc/macros.dist'.
It is mainly used in the *NIX world to identify target platform.
Dunno who defined the '.oc00' name or what it stands for (yet).

[spectest]
I have a self-contained Makefile that does some 'rpmbuild' inspection.
It comes from the MDE4OS2 engine, so I have to manually adjust it a bit.
When ready I will post a dl-link here for anyone interested in inspecting
how 'rpmbuild' sees your environment behind the scenes.

Looking forward to working with you at the RPM front.

Greetz,
  Ben.
Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on February 20, 2021, 09:48:29 pm
Hi
I got this suggestion to try out:

Quote
# 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.

...but this knowledge came with a demotivational complain that I removed. ;D

But it is not what I'm looking for:
Quote
# 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.

Regards
Title: Re: Creating some apps RPM packages
Post by: Ben Rietbroek on February 21, 2021, 05:22:02 pm
Does
rpm --eval %{os2_boot_drive}/Programs
help you?

I also checked a fresh install and %PROGRAMS% is set in CONFIG.SYS,
so it should be in the ENVIRONMENT. So depending on which %section
you are in ${PROGRAMS} might evaluate properly.
Title: Re: Creating some apps RPM packages
Post by: Ben Rietbroek on February 21, 2021, 08:26:43 pm
rpm --eval '%os2_expand_dos_vars %PROGRAMS%'
Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on February 22, 2021, 02:09:09 am
Hi

Here it is my sample to understand better my issue. Right now it is working with the "PROGRAMS" hardcoded.  My goal is to install gotcha on C:\PROGRAMS\GOTCHA\  , just all files there.

 %os2_expand_dos_vars %PROGRAMS% or "$PROGRAMS" works fine for the WPS icon creation since I need the full path.

Under %install. For the mk and cp commands I have the PROGRAMS directory hardcoded instead of bringing it  from the environment variable.

Also on the %files, I have "PROGRAMS" hardcoded.

I think I need a way to bring the %PROGRAMS% without the drive letter, but other ideas and points of view are welcome.
BTW: I know it may not be usual to someone to change the "SET PROGRAMS=" to other directory, but I think it may be better to call the environment variable instead of hardcoding it. (if possible)

Regards
Title: Re: Creating some apps RPM packages
Post by: Ben Rietbroek on February 22, 2021, 05:36:53 pm
Hi Martin,

Quote
I want to find a way to install things on the \Programs\ path without hard coding it.

The thing of course is that the drive-letter for %UNIXROOT% is not necessarily
the same as the drive-letter for %PROGRAMS%.

Since RPM comes from the *NIX world, which has a single-root concept for the
file-system, stored (file) paths in a '.rpm' package _must_ start with a '/',
a requirement that propagates to the %files section of a specfile.

This is why '/@unixroot' exists at the scripting level, where it basically
functions as a placeholder for %UNIXROOT%, which is evaluated at install-time
on the target-system.

If the %PROGRAMS% location at the target-system is on a different drive than
the %UNIXROOT% location, its _true_ location cannot be used as a target for the
package files. One could strip the drive-letter and ':' from %PROGRAMS% and
use that as a destination, which would result in that path being created under
the %UNIXROOT% location.

This is why I mentioned packaging _legacy_ applications earlier.

I think we need to discuss how we would solve this.
Solutions can range from '@unixrooting' such legacy applications,
to using ZIP-files in the '.rpm' and extract that with -d,
to installing to /@unixroot/var/tmp and then moving to %PROGRAMS%,
to rpm-relocating at install-time,
to ...

I have also contemplated introducing additional placeholders, like @programs
or even a more generalized form where '/@?/' could be a placeholder for a drive
so that '/@C/AUTOEXEC.BAT' would be possible.
Any four-char string in the form of '/@?/' would mark such a placeholder where
? is in [C-Z] or [c-z].

Of course the real RPM gurus are at BWW, and I think that once we have a more
clear picture on this, their input and advise is very important.
Title: Re: Creating some apps RPM packages
Post by: Ben Rietbroek on February 23, 2021, 06:20:57 am
So far I found 2 ways to escape %UNIXROOT% for package installations.

[using %pre and symlinks -- dirty hack]
Because %sections become shell-scripts, symlinks work.
So in %pre, which is executed at the target system _before_ files are installed,
a symlink in for instance ${UNIXROOT}/var/programs to ${PROGRAMS} could be made.
In %files then
/@unixroot/var/programs/MyLegacyApplication
would be the entry put in the .rpm and the same path can be used in ${BUILDROOT}.
The fact that var/programs on the build-system is not a symlink while on the target
system it is does not seem to pose a problem.
This method is of course a dirty hack and probably not the way to go.

[using %pre and kLIBC Path Remapper -- not fully tested yet]
This method is conceptually the same, but instead of fiddling with symlinks we
adjust the mapping in the INI-file of the remapper. A small difference is that
the remapper maps /some/unix/path to ?:\some\os2\path so /@unixroot is not
used in the %files section:
/var/programs/MyLegacyApplication
(/var/programs is mapped to %PROGRAMS%)
I have not tested this method completely yet, but it is most certainly better than
the symlink method because it can provide a proper central mapping registry for legacy apps.

I'll be doing some more testing on this stuff and merge that into the spectest example
which I will post here when it has some more flesh on it.
Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on February 24, 2021, 12:26:00 am
/@unixroot/var/programs/MyLegacyApplication

Those are "path choices" I was talking about on the first post   :D

Is really "/@unixroot/var/programs/MyLegacyApplication" a good place for this "legacy OS/2 application" ?
According to wikipedia FHS (https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard), /var is "Variable files: files whose content is expected to continually change during normal operation of the system, such as logs, spool files, and temporary e-mail files. "

Regards
Title: Re: Creating some apps RPM packages
Post by: Ben Rietbroek on February 24, 2021, 09:02:10 am
Quote
Those are "path choices" I was talking about on the first post   :D
Indeed.

Quote
Is really "/@unixroot/var/programs/MyLegacyApplication" a good place for this "legacy OS/2 application" ?
No it is not.

I do experimental stuff using /var and it kinda came with the copy-paste.
Cool to throw the FHS in the argument  ;D

But I have been doing more testing with the Path Remapper and I think it is the solution
to this legacy-apps issue and generic outside %UNIXROOT% dir and file addressing.

I must admit I have always taken that clever piece of software for granted :-[

Using the remapper makes it possible to package legacy applications using their native
directory structure and install them in %PROGRAMS%, even if the
drive-letter for %PROGRAMS% differs from the %UNIXROOT% drive-letter.

My next post will explain using the Path Remapper in more detail...
Title: Re: Creating some apps RPM packages
Post by: Ben Rietbroek on February 24, 2021, 11:08:19 am

== Using the Path Remapper to install Legacy Applications ==

What is it and what does it do ?
The Path Remapper maps /unix/style/paths to ?:\os2\style\paths.
It operates at the kLIBC level so its functionality is available for every
application compiled with GCC-OS2. That includes sh.exe, rpm.exe, rpmbuild.exe
and more generally the whole *NIX framework and friends (https://github.com/bitwiseworks) as provided by Bitwiseworks (https://www.bitwiseworks.com/).

Where is it ?
It is in Computer -> System Setup -> kLIBC Path Remapper.
Click on it and it will show you what remappings are active on your system.

Remapping for legacy applications
Now add the following entry:
From: /remapped/programs
To: %PROGRAMS%

Testing with sh or bash
Open a command-prompt.
Enter sh or bash
(bash is more handy as command retrieval works)
Now do: ls /remapped/programs
You will see the content of your %PROGRAMS% directory.

Remappings are virtual *NIX paths
The interesting stuff is that the From paths are virtual, so they do not exist
on the file-system. And they are only visible to kLIBC applications, which is
why a dir ?:\remapped\programs under CMD does not find it on any drive.
The path is not physically present.

Using the Path Remapper in a specfile
Given that the above mentioned /remapped/programs -> %PROGRAMS% mapping now
exists on your build-box, the /remapped/programs can now be used in %pre and %files
and other %sections as part of the location where files will be installed.
The resulting package.rpm file will show entries starting with /remapped/programs.
And of course it is possible to create %{variables} like:
%define remapped_programs_key   /remapped/programs
%define remapped_programs_value %PROGRAMS%

Installing such a path-remapped package on the user system
Of course the user does not have the required /remapped/programs -> %PROGRAMS%
mappings yet, but those are easy to do in the %pre section. Even better, have
a tiny dependency package do it, so registering the mapping is centralized.

Mapping Persistence
While the mapping is not required for the remapped (legacy) programs to
operate, since they are not aware of any kLIBC magic, the mappings are needed
for the RPM tools to do proper querying, since the location is also entered
into all relevant package databases, including those of YUM when that is used.

Determining a proper mapping name
In my example I used /remapped/programs as the from-path to emphasize the
package uses the remapper. We would need to come up with a name agreed upon
by all parties to have a standard.

One could envision mapping other locations like /remapped/osdir -> %OSDIR% and
/remapped/os2root -> %OSDIR\.. and others. The convention I used here is a
remapped prefix followed by a lowercase name of the %VARIABLE% it maps on.

A spectest example
I am working on a spectest example that creates a few example packages using
the remapper solution. I will cram it all in a GNU Makefile with a
File Commander/2 user-menu front-end for the interface.

Hold on...
Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on February 27, 2021, 09:55:48 pm
Hi

I'm also trying to create a File Commnader/2 RPM installer, but I'm still fighting to create the WPS object for the readme located on %doc.

This is not working, it puts me the %doc on the path as text:
Quote
FC2_README:WPProgram|File Commander/2 Read Me|<FC2_FOLDER>|EXENAME=e.exe;\PROGTYPE=PROG_PM;PARAMETERS=((%doc/fc.txt));OPEN=RUNNING

Ideas are welcome.

Regards
Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on February 27, 2021, 09:58:40 pm
Hi

FYI: These are the rpm OS/2 macros:
http://svn.netlabs.org/repos/rpm/spec/trunk/SPECS/os2-rpm/macros.os2 (http://svn.netlabs.org/repos/rpm/spec/trunk/SPECS/os2-rpm/macros.os2)

Interesting:

Quote
# Converts back slashes to forward slashes.
%os2_fwdslashes()

# Converts forward lashes to back slashes.
%os2_backslashes()
Title: Re: Creating some apps RPM packages
Post by: Ben Rietbroek on February 28, 2021, 05:21:03 pm
Quote
FC2_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.
Title: Re: Creating some apps RPM packages
Post by: Ben Rietbroek on February 28, 2021, 05:34:04 pm

Please note that File Commander (http://silk.apana.org.au/fc.html) is not freeware.

It is worth its purchase fee back and forth and sideways,
so I would encourage anyone to obtain a proper registration for the OS/2 version,
which is still being developed.
Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on February 28, 2021, 10:25:42 pm

Please note that File Commander (http://silk.apana.org.au/fc.html) is not freeware.


Yes, that is the shareware version. It has no registration information at all on the RPM.

Regards
Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on February 28, 2021, 10:50:41 pm
Quote
FC2_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.


It seems it was a mistake, but it didn't produce any issue, neither help with my problem. I still do not know how to get the %doc to set the path for the WPS readme shortcut. Maybe there should be some other alternative instead of %doc to put file on usr/share/doc/-name-version/

Regards
Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on February 28, 2021, 11:41:17 pm
Hi

I found it. odin.spec (http://svn.netlabs.org/repos/rpm/spec/trunk/SPECS/odin.spec) was a good sample that helped me.

The trick was "%{_docdir}. Now the readme is correctly pointed on the WPS object.

Regards
Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on March 01, 2021, 12:01:26 am
Hi

Just a little tweaking to include the icon on the exe.
I think I'm done with File Commander, it was a nice learning. Until Ben let me know the specifics of what should I do to include it on the RPM server once we elaborate more the idea.

Regard
Title: Re: Creating some apps RPM packages
Post by: ivan on March 01, 2021, 01:31:13 am
Hi Martin,

Thank you for a nice chuckle, I say that because the thought just crossed my mind 'you put them together and I take them apart to use'.  No offence meant but I just don't like the stupidity of the RPM system and will get away from it as much as possible, I have even gone as far as denuding the @unixroot directory of as much junk as possible.
Title: Re: Creating some apps RPM packages
Post by: Ben Rietbroek on March 01, 2021, 04:39:41 pm

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)
Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on March 01, 2021, 10:15:39 pm

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)

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/"
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/".

Yes, FHS is a mess, not even the linux guys like it, but it is how it work  :-\

Regards
Title: Re: Creating some apps RPM packages
Post by: Martin Iturbide on March 01, 2021, 10:21:24 pm
Hi

By the way I made some little updates to some packages, trying to standardize how I use the .specs a little bit better, and trying to use lowercase on the package names.

https://archive.org/download/rpm-warp-samples (https://archive.org/download/rpm-warp-samples)

I still have some road ahead to learn to register a WPS class with this and create a install for "Black Hole" as example.

Regards
Title: Re: Creating some apps RPM packages
Post by: Dave Yeo on March 01, 2021, 10:45:50 pm
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/".

Shouldn't system wide high scores go somewhere under @unixroot\var with individual ones under %HOME%
Title: Re: Creating some apps RPM packages
Post by: Ben Rietbroek on March 02, 2021, 05:28:49 pm

== Info on the V.O.I.C.E RPM Packaging Engine ==

The attached dt6202103021446.html.zip will give a first impression
of the automated package building being worked on.
Title: Re: Creating some apps RPM packages
Post by: Andreas Schnellbacher on March 02, 2021, 06:17:27 pm
Ben, that would be a large step forward. I guess most of us don't like to place usual OS/2 apps in the UNIXROOT tree. I didn't know that using OS/2 env vars makes a problem as Martin has pointed out.

Automating the build process is even better. I look forward to your project.
Title: Re: Creating some apps RPM packages
Post by: Ben Rietbroek on March 02, 2021, 11:37:27 pm

Greetings, force behind the NEPMD (http://trac.netlabs.org/nepmd) 8) Project ! 
I'll be picking a few cherries from your works Andreas ...
Title: Re: Creating some apps RPM packages
Post by: Ben Rietbroek on June 18, 2021, 11:08:17 pm

== Update on V.O.I.C.E Developments ==

Silence since my last post
When I am silent it means I'm working... :P
In not too long a time you can follow developments using the 3 websites mentioned
further below in this post.

Availability of the [collab] sub-domain
I was waiting for this sub-domain to be registered, which now has been done.
This is where the «collaboration» website will be hosted.
Its purpose is to provide information on how we can join hands to work together
to realize common goals. More information will be presented on the website itself.

The promised [spectest] example
My first idea was to create a stand-alone spectest example so people
can fiddle with the rpmbuild tool. But later I realized that the whole
idea is to hide the rpmbuild complexity. So I decided that working on
an EPM-variant instead would be better time spent. The spectest example
will most probably be part of the demo-variant -- see below.

EPM Variants
An EPM-variant is a customized version of EPM.
I am first working on a demo-variant and later there will come a specific variant that
focusses on building packages using more high-level interfaces.

V.O.I.C.E Realms
The development work is divided into three main divisions:
EngineeringDevelopment (http://devel.os2voice.org)
CollaborationWorking Together (http://collab.os2voice.org)
ProvisioningProviding Packaged Software (http://rpm.os2voice.org)

Warpstock-EU Presentation (2021)
The underlying concepts of Software Provisioning, together with some more glimpses
under the hood can be found here:
http://collab.os2voice.org/?wseu2021 (http://collab.os2voice.org/?wseu2021)

Greetz,
  Ben.

Title: Re: Creating some apps RPM packages
Post by: Doug Clark on June 21, 2021, 06:36:51 pm
I think the idea of automating, as much as possible, installations is great. 

My biggest demotivation for upgrading AOS versions is the very long time it takes to get all the applications and tools reinstalled and configured after doing a fresh install of AOS  (or ECS or OS/2).

My I make the following observation and suggestion - without knowing how difficult they are to implement?

Prompt the user for where a package/app should be installed.  If using YUM perhaps either a command line parameter to YUM for the install location or a standard environmental variable (e.g. YUM_INSTALL_LOC= ) that YUM would check for the drive/directory to hold the app.  For APM a dialog prompting for location to install at the start of a new install.

Regarding LIBPATH length issues:   For GUI applications, on machines running DragText (which I assume is everyone,)  you can use the Environment page of the Properties notebook of the Program object for the GUI app to set BEGINLIBPATH, avoiding the need to modify LIBPATH.  Each GUI application really should have a Program object anyway.   We would have to persuade Rich Walsh to add a setup string to his DTProgram object for the Environment page/setting in order to use this scheme with automated installs.
Title: Re: Creating some apps RPM packages
Post by: Dave Yeo on June 21, 2021, 08:08:54 pm
Hi Doug, couple of points.
At this point, all new versions of AOS should update or, in the case of 5.0.x to 5.1.x upgrade, so everything should keep the same configuration and whatever you have installed are still installed. There's a couple of gotchas like the update procedure leaving %TMP% pointed at x:\var\temp that need a quick config.sys edit.
YUM and the ANPM front end use %UNIXROOT% to decide where to install the RPM apps. As originally design %UNIXROOT% could contain a PATH but since the RPM people took it over, only a drive letter is supported. A PATH still might work but is untested.
During the install there is a point where you are asked about %HOME%, %UNIXROOT%, %TEMP% and IIRC another with the defaults pointing at the install volume. You can accept the defaults or change them.
For the LIBPATH issue, either your method of setting the BEGINLIBPATH in the program object or alternately, a script that sets BEGINLIBPATH etc which I usually use. Good practice to inherit any previous BEGINLIBPATH settings to like SET BEGINLIBPATH=x:\foo\lib;%BEGINLIBPATH%
There's also ENDLIBPATH for the odd situation, I use it for Gopher and Webexplorer with my Ver 4 \tcpip\lib etc coming last in LIBPATH so only DLLs that aren't already present on AOS are loaded.
Title: Re: Creating some apps RPM packages
Post by: ivan on June 21, 2021, 09:28:03 pm
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.  The last time I opened the yum package manager (had to look up what it is called) was when we were told about the QT5 port - couldn't find a full runtime so gave up looking.

All my tools are in subdirectories of the 'tools' directory, likewise utilities.  Those two directories are stored on my NAS boxes and get copied over to any new install of OS/2 / ArcaOS and I will continue doing so as long as they work on my computers, I have had to drop a couple of utilities because the MMRE driver does not communicate lan speed and throughput in a form the programs expect.
Title: Re: Creating some apps RPM packages
Post by: Doug Bissett on June 21, 2021, 10:28:58 pm
Quote
I have never understood the reason for using RPM/YUM as an installer in OS/2/ArcaOS.

It is very simple. That is the way some of it is being done, by choice of those who do the work. They have no intention of changing that.

Quote
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.

WarpIn has not been abandoned, it is still used when the person making the package wants to do it that way (many packages in ArcaOS are installed using WarpIn). It can also be done with ZIP files. The choice depends a LOT on what is being packaged, and what the dependencies are.

Quote
I too do not update my install unless it is something I can download and install myself.

VERY BAD idea. I can't emphasize that enough. The YUM package manager does a LOT more than simply install things (use the Arca Noae Package Manager - ANPM to make it simple, and get it done right). If you don't use RPM/YUM, you can be missing parts of what is required (plus you can end up spending DAYS trying to sort it out). It also makes sure that all of the parts end up in the proper place (it is NOT just a simple target). Many Linux ports simply assume locations, so even if you have something, somewhere, it may not be found, if it is not where it is assumed to be.

RPM/YUM is just another package installer, made MUCH easier to use, when you use ANPM to run it (and ANPM has more features coming). It can be somewhat tricky to convert an older system to use  RPM/YUM (there are way too many things that users did before, that can mess it up). It is easy if you use it from a new install, and NEVER try to outsmart it.
Title: Re: Creating some apps RPM packages
Post by: Doug Clark on June 22, 2021, 01:31:28 am
Dave:  Thanks for the info on updating AOS.  I will give the latest version a shot.  (Now if it were only that easy to update from eCS to AOS - oh well..)

Ivan:  I too love WarpIn - great product, although it needs a better database for storing installed app information;  the 2 levels that INI files provides is not enough.  But I can understand and agree with RPM for the unixy stuff.  That stuff is SO intertwined and complicated.  And I am actually OK with UNIXROOT being a drive letter instead of a path for the messy, snakey, interdependent unixy stuff.  That stuff is so complicated that I am kinda scared to even look down in the depths of UNIXROOT.

What Martin was talking about was RPM-izing legacy type OS/2 apps.   That has lots of benefits, and some downsides.  It is legacy apps (and SOME unix type apps like Firefox) that I want the ability to chose where stuff goes.  Here's  why:  I run a number of Win-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.  I also am running SSD and rotating disks and I try and put the stuff that changes a lot (Swapper, firefox cache, etc.) on the rotating disk and keep the test on the SSD partitions.

So I think we absolutely need the ability, at least with legacy apps, to chose where they go.  And it would be nice to have the ability to choose even with some unix apps.

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.  But it is nice to be able to select a list of apps (like with APM) and install them all at once.. And for them to be available from one (virtual) locate.

Title: Re: Creating some apps RPM packages
Post by: Dave Yeo on June 22, 2021, 02:42:53 am
@Doug, there is hope that Arca Noae will add the ability to upgrade eCS and even Warp V4 to AOS 5.1. Whether it gets done is questionable, with the Warp v4 upgrade unlikely to happen.
As for Firefox, which is more of a cross platform app then a *nix app, you can just move it. Likewise for most of the programs included with AOS and installed under \Programs (check config.sys though).

@Ivan, the problem with Warpin is it doesn't handle dependencies too well, especially updates to those dependencies. Throwing everything under one directory is fine as long as you always use YUM or ANPM to manage them. Doug B. explained most of the benefits and pitfalls of not using it. Installing QT5 is as simple (or should be) as yum install qt5 and it pulls in all dependencies.
Title: Re: Creating some apps RPM packages
Post by: Doug Bissett on June 22, 2021, 04:34:59 am
Quote
although it needs a better database for storing installed app information;  the 2 levels that INI files provides is not enough.

What is missing?

Quote
What Martin was talking about was RPM-izing legacy type OS/2 apps.

Which is okay for learning how to do it. I hope he doesn't actually try to distribute old style OS/2 apps that way. It is not appropriate. Some of them are not even appropriate for WarpIn.

Quote
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.

Actually, that is not a restriction. You should use https://hobbes.nmsu.edu/download/pub/dos/2gbfix.zip (https://hobbes.nmsu.edu/download/pub/dos/2gbfix.zip), possibly with the patch to lower the returned space even further https://hobbes.nmsu.edu/download/pub/dos/2GBFIXPA.ZIP (https://hobbes.nmsu.edu/download/pub/dos/2GBFIXPA.ZIP). It doesn't matter how big the drive is, the biggest number that DOS will "see" is slightly less than 2 GB. 2gbfix is included in ArcaOS. DOS can only "see" 8.3 file names too. All others are invisible.

Quote
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.

RPM is "more complicated" because it usually needs far more links to dependencies, but the person who builds the program usually knows what is required, so it is easier for them to do it. Other than that, it is just a "learning curve". WarpIn can burn you pretty bad, if you don't get it right, and it doesn't handle dependencies, which means the user can also mess it up. RPM/YUM can also burn you, if it isn't done properly.

Neither installer is "perfect". They are what they are. The main purpose of both, is to make it easy for a user to get a program installed correctly, so it will work. In most (unfortunately, not all) cases both work as they should.

One of the reasons why I object to restoring old programs to HOBBES, is that some of them were removed because the WarpIn installer was doing bad things.
Title: Re: Creating some apps RPM packages
Post by: Doug Clark on June 22, 2021, 06:17:34 am
@Doug B  sort of quoting "What's wrong with 2 levels in the WarpIn database?"

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.

To repeat: I like WarpIn.  I think it is a great product.  Installing applications can be surprisingly difficult and complex - especially when designing to allow for updating.  And WarpIn, on the whole, does an excellent job.

@Doug B. and @Dave   Yes I can move firefox after it is installed, and could probably move some other Unixy applications installed by RPM after they are installed.  It would not be the end of the world - although moving some of them would be very difficult (e.g. Odin.).  And yes I could make a boot partition larger than 2 gb and use 2gbfix to work around the issue for those old Dos/Windows apps.  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. 

It just seems to me (my opinion, FWIW) that any/all decent installers should allow the user to select the destination of a application being installed, when that is possible.  Obviously some system components have to go in specific locations - but for those that don't, why not provide the choice?

@Doug B.  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 spent quite a bit of time years ago on the WarpDoctor project in an attempt to build something like APM for OS/2 VOICE.  I even spent time modifying WarpIn so that it would retrieve packages across the internet and install them on a local machine in that effort - and gave up.  It was, and is, a very big project.  I am fully in and supportive of APM and what Martin and Ben are attempting to do, and I recognize how difficult and complex it is.  Thank you Martin, and Ben, and everyone else working on this, for your time and effort.

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.
Title: Re: Creating some apps RPM packages
Post by: Dave Yeo on June 22, 2021, 07:31:11 am
Unluckily RPM (and YUM and ANPM are just frontends for RPM) was designed for Linux, following the *nix tradition of minimal file directories below root, along with the capability of having them on different partitions/disks. I also think it was designed to collect consulting money. To hack it to allow installing programs in different places would probably be hard if not next to impossible.
BTW, to uninstall the screensaver takes 3 or 4 clicks, click the first package, scroll down and shift-click the last, right click and choose uninstall and perhaps another click to verify that you want to uninstall. And even with all those packages, it is still hard and probably would take more packages to make it NLV aware on the desktop. Welcome to ideas how to do that.
Also the screensaver is an example of other shortcomings, it needs a few RPM packages installed and currently there is no way to force those packages to be installed.
Another interesting problem going forward is that AOS is going to have several localized versions to complicate things.
Title: Re: Creating some apps RPM packages
Post by: Doug Bissett on June 22, 2021, 08:26:30 am
Quote
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.

That is true. Back when WarpIn was developed, it was unusual to have more than one component. Three, at the most, so it wasn't much of a problem. If you want an example of a complicated WarpIn installer, have a look at the GENMAC installer. One of the "problems" with WarpIn, is that it is very flexible, and can easily be augmented using REXX. Lots of people have invented ways to use that, and sometimes it can cause problems.

You can select more than one package, using the standard selection methods. If it was packaged in a way that keeps all of the parts together, that is pretty easy. To use DSS as an example, click the first entry, move to the last entry and Shift click. They will all be selected, and you can RMB to uninstall them all. I suspect that it would be far more work, than can be justified, to change that, and it would probably break a lot of things that work now.

Quote
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.

You do have the choice. Very few things must be on the boot volume. Back when DOS, and WinOS2, support was created, a 10 MB (yeah, "MB") hard disk was HUGE. The disk size did not become a problem until disk larger than 2 GB became available. IBM never fixed the problem, so somebody developed 2GBfix to avoid the problem (there are a couple of others, but 2GBfix works best). If you don't want to use that, it is your choice. Probably the best approach is to have a small partition dedicated to DOS/WinOS2 programs. That could be the C: drive, if you make your boot drive something other than C:. Another way to avoid using space on the boot drive, is to put the RPM/YUM stuff on a different drive.

Quote
When the better way is to simply give the user the choice on where to install a product when using APM/YUM/RPM.

Using WarpIn, you can select where to put things, but it usually doesn't make sense to do that. The default locations (as defined in the WarpIn settings, which I usually change, to my own preferences, at OS install time), are usually best. I assume you meant ANPM, not APM (a power manager) with RPM/YUM. You need to realize that RPM/YUM is designed to work with Linux, which usually has fixed (not selectable) locations for things. A lot of that was never changed, because it makes it easier to port programs from Linux. In fact, there are very few programs that actually get installed using RPM/YUM. Almost all of that stuff is support for Linux ports, which are often installed by WarpIn. There is a RPM package for Firefox, but I doubt if it will ever be pushed to the release  channel, simply because Firefox is no longer being ported for OS/2. From what I hear, the new browser (Otter) will be an RPM package (probably with no other options for installing, because of the complexity involved).

Quote
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.

Old style OS/2 apps are not suited to distribution as RPM packages, and it would be a lot of work to do it, for little, or no, gain. Other things could use a little polish, and it would probably be easier to repackage the very old programs as WarpIn packages (many of them just need to place the files, and add an icon). RPM/YUM is useful when there are many *NIX requirements. It is not as useful when it is a stand alone program, but it should be possible to do it.

Quote
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.

Perhaps so, but that would make it a LOT more difficult to port RPM and YUM (ANPM just uses some intelligence to run YUM). They are not designed to do things like that, and changing too many things tends to break other things. In fact, it is probably possible, if the the person building the package can find a way to do it. I understand that scripts are used to do some things, perhaps they can ask where to put things, when the package might actually work in non standard locations. The main "problem" is that doing things like that, makes supporting the whole thing a lot more complex, and one thing that we don't have, are a lot of support people to try to figure out what some user has done to themselves. It happens often enough when it is a supported configuration. The other problem is that some future change might make whatever was done fail to work. Then, who is going to figure that out? There just aren't enough people to do it all.