• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

RPM packager

Started by minou, 2011.08.28, 07:35:09

Previous topic - Next topic

Do you want an RPM/YUM implementation for OS/2 that uses the Unix/Linux "Filesystem Hierarchy Standard" (/home, /var, /usr, /etc..)?

Yes
14 (41.2%)
No
18 (52.9%)
I don't know
2 (5.9%)

Total Members Voted: 0

melf

dmik,

As far as I understand your aim it is to implement the RPM installer in order to ease installation and updates of both *nix ports and native os2-software. To better suit *nix-ports you also want to implement FHS as the directory tree standard in eCS. Morover the eCS command line will be replaced by "e.g. sh.exe instead of cmd.exe", while the eCS command line will be left for compabilitity reasons.

Many users of eCS have used OS2-eCS for a long time and have developed habits in their use and ways to manage problems. I guess that quite a few rely on eCS for their business investments. In total many eCS users also have a grounded knowledge of their OS. Morover eCS is not just any OS, it is an OS into which people also have invested a great deal of feelings, we all know that and the reasons why.

 
I don't distrust your good will and effort to provide eCS with more software, but I wish you would understand peoples feeling about your idea. You are trying to argue in an over-rational way while not being able (or willing) to understand the resistance you meet. You are forcing to people a *nix layout and way of thinking and handling software. Morover you take the ordinary eCS users grounded knowledge from them as things become lesser transparent (RPM knows but not you) and lesser flexible (can't organise software the way you want), in that way hampering their work habits and ways to deal with problems. For many eCS users this is provoking - it is a little bit like saying to someone: "from now on you should speak spanish (or whatever language), you can't use your language anymore".

I think it would be good if you stopped arguing for a moment and tried to listen. RPM might turn out to be good, but eventually implemented in another way -  a way that is acceptable to users and can preserve OS2-eCS values - both practical and emotional.You may say that the use of RPM is voluntary, and of course it is, we can choose not to use it. But on the other hand you can choose too, you can choose to listen to what people are communicating.
/Mikael

dmik

melf, your basic understanding of our idea is correct.

But I don't know what makes you think that we don't understand your concerns. The fact that we don't want to go the old way doesn't mean that we don't understand it (personally, I've been using OS/2 since 1993 and I had exactly the same concerns regarding RPM and FHS as you some time ago, even after getting some good Linux experience). What I want to say is that we are not able to provide quality software for the old OS/2 environment without changing it in some ways -- can it be more clear? Almost all system components in OS/2 are outdated, bogus and have limited functionality. This includes the base and the GUI libraries, the command line tools, CMD.EXE, the file system layout, config.sys and lots of other things. At some point this made the task of writing/porting the new software to OS/2 unmanageable. So, for us, the changes we are proposing are inevitable. You got it wrong. We didn't ask you about what file structure we should use on the boot drive and which installer framework we should port. What we are asking you about is this:

1. What are your most important concerns regarding RPM? We will listen and provide a solution, when possible, if it does not already exist.
2. How can we make this transition easier for you? We wish it to be as easy as possible for the end users.
3. What do you want to know about the upcoming changes? We are ready to help you and we want to give you understanding of things.

These are the current concerns we see, and our answers to them:

1. No GUI. -- Point taken, this is being worked on. Please, |yum install| until then.

2. No way to select the installation directory (imagine if the drive with UNIXROOT has no free space).  -- Please believe us, you will not want to do that after getting used to RPM. Given the size and the price of modern hard disks, it is not a problem to just get a bigger one to fit all you need. We may also come with a solution to at least select the target drive later (when the GUI is done).

3. No way to select the installation directory (I want things to be sorted *my* way).  -- Each end-user application provided by us will have a WPS object. You can move these WPS objects on the Desktop to sort things the way you like. See also 5. and 6.

4. I hate FHS. -- If you look at that carefully, it's just *two* new directories (/bin, /usr) in the root. /etc, /tmp, /var and /home don't count because they already exist in eCS (/etc and /tmp even exist in the original OS/2 under slightly different names). Two new directories is not that much, is it?

5. I hate application files spread across different directories. -- We know this is unusual for you. We agree that keeping all files in a single directory simplifies housekeeping, but this is not always possible on OS/2 due to some native limitations that we can't fix. And given that RPM always knows what files comprise the application no matter where they are, it does not actually make housekeeping (installing/uninstalling) more difficult in its case. If you are concerned about moving applications around for sorting purposes, see answers 2. and 3.

6. I not only want sorting, I also want to be able to quickly move the application to another machine. -- Let RPM do it. Given its knowledge about application files, it will be faster than you (and no removable medium is necessary).

7. I want to use the application on a machine where I have no Internet connection. -- Take its .rpm file. It is really easy to install the application from it w/o the Internet connection.

8. I want to backup my applications. -- All applications we provide are backed up on our servers. No need to backup them locally.

9. I don't want automatic software updates. -- RPM doesn't do that. It only behaves if you ask it to.

10. I want full manual control. -- We also provide ZIPs for all applications.

11. No transparency of things. -- Everything is transparent, it is a matter of learning a couple of RPM commands. Will not be necessary when the RPM GUI comes up.

12. You are ****. -- We love you too!

As you see, all your current concerns have or will have solutions. Yes, it requires you to slightly change your habits and to learn something new. But we sincerely believe this is for your own best and we will try to minimize the learning curve. Eventually, this will make your OS/2 life easier. And it will surely prolong the life of OS/2 itself.

CDRWSel, you are ignored.

Fahrvenugen

#122
Quote from: dmik on 2011.09.06, 20:51:59
Quote from: Fahrvenugen on 2011.09.06, 19:14:29
I disagree -  I drag and drop entire OS/2 based apps all the time and rarely have a difficulty.  This is one of the features of OS/2 that sets it apart from  other operating systems - it easily allows you to do this - move around either data files or entire apps without breaking things (and it even updates your shadows and objects properly) - all due to the OO technology built into the system and WPS.

We do not speak about WPS here, we speak about moving applications from one folder to another on the hard disk.



Yes, that is exactly what I often do.

I'll install an app into a folder on the hard drive and later drag it to another folder on the same drive and it'll still work.

Or I'll drag it to another drive with a different drive letter, into a different folder, and it'll still work.  And all the objects on the desktop for that app get updated too.

So yes, I do know what I'm talking about - moving applications from one folder and / or drive letter to another, using drag and drop.  And yes, it does work for many OS/2 based applications.

I've used this technique to test apps before using them in production.

I've also used this to deploy apps that run from a network share - set them up on my local machine, copy the app over to a network share, then add an object for the app to all the desktops available on the network (and doing this involves a single command).

Anyways...

Please understand that I'm not trying to attack or be overly critical of RPM / YUM - I'm just trying to offer a view of some of the ways that - as an OS/2 / eCS user - ways that I currently use the OS.  I'm also understanding more that RPM / YUM is one of those things that is ultimately up to the end user if they want to install and use in the first place.  Those who want it can use it, those who prefer not will likely not use it,  just as developers who prefer to distribute their installers with ZIP / IBM Installer / WarpIn / Feature Install / a plain old REXX script / etc will likely distribute with their choice of installer.


Dmik, also please don't misunderstand me.  I do appreciate all the work that you and other developers are doing to keep the system relevant and useful.  I admit that I do share some of the concerns that have been expressed, and as a result I likely will be one of the more cautious users when it comes to RPM / YUM. However I also don't want this to be a deterrent to development.  Each user will have different needs and comfort levels when considering introducing new software on their system(s).  Just as some users will have DOS and WinOS/2 support installed and some users won't install it, some will install Java and some won't, I can see YUM / RPM falling into a similar category.


CDRWSel

I just read dmik arguments and answer, as I wrote, he's adapting and older process to eCS.

The base idea is not bad (and well developer oriented) but the implemented process and how it should work needs a lot of work and add flexibility needed by end users (as read under this thread) to go in the direction other OSes developers are taken, more flexibility and portability  

Some Companies are know looking how to install applications on removable storage for portability which is part of the futur. End user plugin his USB removable storage on an available hardware (like wifi is now free accessible) and have the personal desktop ready.
Of course, the removable storage would be very secured when encrypting all data using a PGP tool.    

The other direction would be tablet system (it looks like a revolution and easy to use for resellers and home use) which mostly use android OS or apple OS. The OS has to be responsive and small in size on the burned in SSD chips.

ivan

dmik,

QuoteThese are the current concerns we see, and our answers to them:

1. No GUI. -- Point taken, this is being worked on. Please, |yum install| until then.

No comment.

Quote2. No way to select the installation directory (imagine if the drive with UNIXROOT has no free space).  -- Please believe us, you will not want to do that after getting used to RPM. Given the size and the price of modern hard disks, it is not a problem to just get a bigger one to fit all you need. We may also come with a solution to at least select the target drive later (when the GUI is done).

This is only relevant in a single user concept.  Business use has a different usage pattern that is usually a boot partition that is kept as small as possible and is transferred from an image file to the target machine.

Quote3. No way to select the installation directory (I want things to be sorted *my* way).  -- Each end-user application provided by us will have a WPS object. You can move these WPS objects on the Desktop to sort things the way you like. See also 5. and 6. 

Not good enough!  We have images of the tools directory and its structure as well as the utilities directory which can be placed on target machines as necessary - your idea is still single user.

Quote4. I hate FHS. -- If you look at that carefully, it's just *two* new directories (/bin, /usr) in the root. /etc, /tmp, /var and /home don't count because they already exist in eCS (/etc and /tmp even exist in the original OS/2 under slightly different names). Two new directories is not that much, is it?

All you are doing here is fragmenting programs (see also 5).

Quote5. I hate application files spread across different directories. -- We know this is unusual for you. We agree that keeping all files in a single directory simplifies housekeeping, but this is not always possible on OS/2 due to some native limitations that we can't fix. And given that RPM always knows what files comprise the application no matter where they are, it does not actually make housekeeping (installing/uninstalling) more difficult in its case. If you are concerned about moving applications around for sorting purposes, see answers 2. and 3. 

You might have a small argument to do this on a single system - it does not work in any business situation I know of.

Quote6. I not only want sorting, I also want to be able to quickly move the application to another machine. -- Let RPM do it. Given its knowledge about application files, it will be faster than you (and no removable medium is necessary).

Again, this is not for use in a business.

Quote7. I want to use the application on a machine where I have no Internet connection. -- Take its .rpm file. It is really easy to install the application from it w/o the Internet connection.

You will find in business what you are suggesting does not work - the admins have control of what may, or may not, be installed and the company firewall tends to stop the acquisition of things from the internet.

Quote8. I want to backup my applications. -- All applications we provide are backed up on our servers. No need to backup them locally.

Again single user thinking, it won't wash in a business.

Quote9. I don't want automatic software updates. -- RPM doesn't do that. It only behaves if you ask it to.

10. I want full manual control. -- We also provide ZIPs for all applications.

11. No transparency of things. -- Everything is transparent, it is a matter of learning a couple of RPM commands. Will not be necessary when the RPM GUI comes up.   

Yet more single user thinking.

Have you actually asked sys admins of businesses how they administer their IT?  Because as I read it you are focused on single user usage only.


dmik

Quote from: Fahrvenugen on 2011.09.07, 07:44:55
So yes, I do know what I'm talking about - moving applications from one folder and / or drive letter to another, using drag and drop.  And yes, it does work for many OS/2 based applications.

I didn't say that this does not work. You probably don't remember, but I said that this will only work for simple apps with no dependencies. This is not the case for modern apps we provide. Even a trivial kdiff3 utility needs the Qt4 runtime. Packing the Qt4 runtime with each application will increase its installed size by 40-50 MB even if the application itself is 500 K. This is insane and this will create an incredible mess of DLLs on your system.

Quote
I've used this technique to test apps before using them in production.

You don't need this technique with RPM. You can safely install/uninstall as many times as you want. Uninstalling the application will bring your system to the exact state it had before installing (except that the configuration file in /home/user, if any, will not be deleted, but this can't harm).

Quote
I've also used this to deploy apps that run from a network share - set them up on my local machine, copy the app over to a network share, then add an object for the app to all the desktops available on the network (and doing this involves a single command).

You don't need network shares to deploy apps this way with RPM. And this gives you significant benefits.

Thank you for your appreciation.

dmik

#126
Quote from: ivan on 2011.09.07, 13:17:12
Quote2. No way to select the installation directory (imagine if the drive with UNIXROOT has no free space).

This is only relevant in a single user concept.  Business use has a different usage pattern that is usually a boot partition that is kept as small as possible and is transferred from an image file to the target machine.

The whole concept of the managing software installer is rather irrelevant in this usage pattern since the master image is static and carefully hand crafted anyway. But you still benefit a lot from RPM here because it allows to do *controlled* installs and structured updates of any software. This may simplify things when creating the master image and it also lets you deploy some applications right on the target workstations w/o the need to recompose/retest/redeploy the master image, which is obviously much faster and requires much less effort.

Quote
Quote3. No way to select the installation directory (I want things to be sorted *my* way). -- Each end-user application provided by us will have a WPS object. You can move these WPS objects on the Desktop to sort things the way you like.

Not good enough!  We have images of the tools directory and its structure as well as the utilities directory which can be placed on target machines as necessary - your idea is still single user.

The quoted answer is for the single user indeed, and not for your case at all. For you the answer is above. RPM lets you manage the images of such tools directories much more effectively than any other instrument you currently have. Much more effectively means less money on support.

Quote
Quote5. I hate application files spread across different directories.

You might have a small argument to do this on a single system - it does not work in any business situation I know of.

What do you mean when you say "a small argument"? I already presented many big arguments for doing so. Please read my posts. And what do you mean when you say that it doesn't work in business? It is not clear from your vague answer.

Quote
Quote7. I want to use the application on a machine where I have no Internet connection. -- Take its .rpm file. It is really easy to install the application from it w/o the Internet connection.

You will find in business what you are suggesting does not work - the admins have control of what may, or may not, be installed and the company firewall tends to stop the acquisition of things from the internet.

You seem to not understand what you are citing. I said that you *don't* need the Internet connection to have the ability to use RPM managed software if you want so. Regarding "what may, or may not, be installed", RPM gives you precise control over this. You probably don't remember but I already wrote that you can easily create your own RPM repository located in your intranet behind your firewall and stuff it only with the software you trust and need.

Quote
Quote8. I want to backup my applications. -- All applications we provide are backed up on our servers. No need to backup them locally.

Again single user thinking, it won't wash in a business.

This sounds like naked words to me. Please clarify what you mean.

Quote
Have you actually asked sys admins of businesses how they administer their IT?  Because as I read it you are focused on single user usage only.

I already said that we are focused on *general* usage. This includes the generic patterns of both personal use and business use. Most complaints here are from "single" users, hence are our answers. For you we have different ones.

CDRWSel

#127
Because I spoke about portableapps, here is a comment I would like more often see from some developers under my prefered OS.

Customizable App Organization With Automatic and Custom Folders
You asked for it, you got it

The menu which includes install/uninstall/update applications only uses 4MB as compressed file. Here is the link which, I think, could give good ideas and improve our prefered OS.
http://portableapps.com/news/2011-08-08_-_portableapps.com_platform_2.0_pre-release_3_released  

lewhoo

Just to give a notice, I am familiar with RPM and yum, I have to use it nearly every day in it's native enviroment, so moslty the new thing I'll have to learn will be the GUI installer.

Quote from: dmik on 2011.09.07, 05:32:32

2. No way to select the installation directory (imagine if the drive with UNIXROOT has no free space).  -- Please believe us, you will not want to do that after getting used to RPM. Given the size and the price of modern hard disks, it is not a problem to just get a bigger one to fit all you need. We may also come with a solution to at least select the target drive later (when the GUI is done).

Simply not true. I just could say that, because I know much better how I fill using yum/rpm on linux and what I want. But I'll give some arguments:

1. small disks on notebooks, not easly changable
2. Multi-system installs
3. And finally - I always hated argument "just buy a new hardware". This is Microsoft argument. This is the way that most linux and windows software became badly written and unoptimized. I don't like buying new hardware because I am forced to. For me, many times, changing to a new hdd ment changing the whole machine.

Quote
3. No way to select the installation directory (I want things to be sorted *my* way).  -- Each end-user application provided by us will have a WPS object. You can move these WPS objects on the Desktop to sort things the way you like. See also 5. and 6.

For me this is not the solution. This is a fundamental change in the OS and, I am completely sure of that, a downgrade. Linux was made to be managed by an admin, who posseses magical knowledge, not simple or even experienced (power) users. Now they attempt to make some workarounds around this fact. Here you try to implement such a workaround on a system,which has completely different idea behind it's design - here I am an admin, but an admin who does not have to possess all the magical knowledge and spend 10 hours a day learning it's system, to get things organized as I like in my system. I am a power-user. For me, one of your main tasks should be allowing power-user to remain the main user of OS/2. Older software allows that. I know this can be difficult with unix-ported software, because no idea of power-user exists on linux/unix. But that's a big part of core of what OS/2 is and why it is unique. And pleasedo not say - you will have a zip package. Resolving dependences manually and so on is most of the time task managable by an admin,not a power-user.


Quote
5. I hate application files spread across different directories. -- We know this is unusual for you. We agree that keeping all files in a single directory simplifies housekeeping, but this is not always possible on OS/2 due to some native limitations that we can't fix. And given that RPM always knows what files comprise the application no matter where they are, it does not actually make housekeeping (installing/uninstalling) more difficult in its case. If you are concerned about moving applications around for sorting purposes, see answers 2. and 3.

So please make a browser of RPM "knowledge" with some kind of app like FC/2. With which I could move files around, see where file belongs, get apps automatically updated with information where their files now are. Well, I know that this would be a work comparable to writing the RPM from a scratch, so this is just to give you a hint. So for the beginning, just simplify getting files informations from RPM with a gui installer - I mean, don't leave us with a pure command-line (or GUI) listing,which we have to parse with our eyes or grep/awk/less, as is a common situation on linux.

Quote
8. I want to backup my applications. -- All applications we provide are backed up on our servers. No need to backup them locally.

How about backing up user data?


I think I could appreciate OS/2 version of RPM/YUM (not a port, a version), that would have reasonable gui, allowed to install every file where I want it to, and allowed me to browse every info I want in a human-readable way. This is my personal opinion as an end-user.

lwriemen

#129
I don't understand the all or nothing approach. Maybe that's not what's being proposed, but it has read that way.

Let %UNIXROOT% be where the FHS is placed. Ideally use a volume (right term?), so it can be re-sized larger if more hard drive space is needed. Let all the ported *nix apps play within %UNIXROOT% and leave the OS and all native apps to the usual arrangements.

I hated the PROGRAMS directory eComStation introduced; it was a Windows artifact, and not how OS/2 works. Forcing everyone onto the FHS would be another illogical, unnecessary change. Let OS/2 be OS/2. It can support many things at once.

Now anyone who wants *nix ports to behave like OS/2 apps, get over it! They are ports, and they weren't made for OS/2! If the ports are made easier by installing the FHS somewhere, then that is a benefit for all. The wishlist for a rpm/yum front-end can be started, so you can specify (e.g.) where to place the shadow for execution during install.

Fahrvenugen

#130
Quote from: dmik on 2011.09.07, 14:00:39
Quote from: Fahrvenugen on 2011.09.07, 07:44:55
So yes, I do know what I'm talking about - moving applications from one folder and / or drive letter to another, using drag and drop.  And yes, it does work for many OS/2 based applications.

I didn't say that this does not work. You probably don't remember, but I said that this will only work for simple apps with no dependencies. This is not the case for modern apps we provide. Even a trivial kdiff3 utility needs the Qt4 runtime. Packing the Qt4 runtime with each application will increase its installed size by 40-50 MB even if the application itself is 500 K. This is insane and this will create an incredible mess of DLLs on your system.

So essentially from what you're saying this isn't all that different from apps which use the OS/2 system DLL's, emx DLL's, the Libc dll, etc.  The apps will need to be able to see the libraries they use.

Quote
Quote
I've used this technique to test apps before using them in production.

You don't need this technique with RPM. You can safely install/uninstall as many times as you want. Uninstalling the application will bring your system to the exact state it had before installing (except that the configuration file in /home/user, if any, will not be deleted, but this can't harm).

I understand what you're saying, but in a production environment I wouldn't deploy an app until properly tested on a system set up for testing stuff. But this has little to do with RPM / YUM though - it would apply equally for any application regardless of how it is installed.

Quote
I've also used this to deploy apps that run from a network share - set them up on my local machine, copy the app over to a network share, then add an object for the app to all the desktops available on the network (and doing this involves a single command).
Quote
You don't need network shares to deploy apps this way with RPM. And this gives you significant benefits.

Thank you for your appreciation.


On this point, I think you're not fully understanding me.  I'm not talking about deploying and installing an app from a network share on individual workstations.  I'm talking about having the app sitting on a network share and running it directly from that share.  The app does not get installed locally on the workstation - it sits on the network, and can have multiple workstations running the same app (accessing the application EXE's and DLL's through the network).

The reasons for this can be multiple.  For security, you can easily control what apps can be run on what workstations and by what users based on the user login and the groups the user is a part of.  If an update or change needs to be made to an app, you only need to update / change / fix the app in one place and everyone gets the update (no need to patch multiple workstations like you would in an environment where the app is installed on multiple workstations).  You can also (using remote boot type setups) run with diskless workstations if you want (similarly to how Workspace on Demand works) and have no local machine storage for anything other then a swap file, no local hard disk (other then for a swap file - improving both central management, site security, centralized site backup, etc).

Admittedly running Linux ports from a network share in this manner may not work within the FHS / YUM / RPM model.

I hope this provides a little insight into what I'm talking about with regards to running apps from a network share.  Thanks for your replies and the continued discussion!


aschn

Quote from: Fahrvenugen on 2011.09.07, 17:12:59
Quote from: dmik on 2011.09.07, 14:00:39
Quote from: Fahrvenugen on 2011.09.07, 07:44:55
So yes, I do know what I'm talking about - moving applications from
one folder and / or drive letter to another, using drag and drop. And
yes, it does work for many OS/2 based applications.

I didn't say that this does not work. You probably don't remember, but
I said that this will only work for simple apps with no dependencies.
This is not the case for modern apps we provide. Even a trivial kdiff3
utility needs the Qt4 runtime. Packing the Qt4 runtime with each
application will increase its installed size by 40-50 MB even if the
application itself is 500 K. This is insane and this will create an
incredible mess of DLLs on your system.

So essentially from what you're saying this isn't all that different
from apps which use the OS/2 system DLL's, emx DLL's, the Libc dll,
etc. The apps will need to be able to see the libraries they use.

Fahrvenugen, as soon as an app stores a path that points to a file
object of the installation using an absolute pathname, your are lost
with drag and drop. The applies for almost all apps. IBM never
managed to finish the idea behind it. Some details:

Usually installed OS/2 (not ported) apps write their installation
path to OS2.INI. If you move the installation files, the program
objects were synchronized, but the entry in OS2.INI not. Apps have
to be specially prepared to handle that situation. E.g. even EPM
contains code to handle it, but it's full of bugs.

Please let us end the discussion about drag-and-drop ability, even
OS/2 apps don't know how to handle that.

--
Andreas Schnellbacher

Pete

Hi Andreas

With regard to the drag'n'drop: some os/2 apps do write an install path to os2.ini; a lot do not.

However, even apps that write this path data in os2.ini do not seem to have problems - os2.ini seems to get updated with the new path when the app gets moved.

Regards

Pete

dmik

lewhoo, about hard disks. Given that in order to install all software avaliable for OS/2 you will barely need a partition more than 10G (remember, we don't calculate your data, it's separate), even five years old notebooks have space for 10 eCS installations. So this argument has nothing behind it. As for multiple eCS installs, RPM does everything for you, so it makes no problems to simply have everything installed everywhere and only share data. Regarding your 3rd point, you don't understand one simple thing -- the cost of maintaining software so that you can toss it around in any possible way and it still works is zillion times higher then hard disk space costs. Wake up! Nobody will do it. It makes no sense in 2011.

I don't undertsand why moving to the WPS level is not a solution for you. You don't present arguments. "It's a downgrade" and "other software works" are not arguments. "I don't feel okay with that" is not an argument either -- it could be if we were trying to sell a million egg slicers to houesewives. But this is just not the case.

The backup of user data is to be done the usual way. Copy/zip/whatever your %HOME% folder to a safe location.

lwriemen, there is no nothing or all approach. ZIP is not nothing. Yes, you may use logical volumes to seamlessly increase the hard disk size, this is entirely up to you (end-user). The concept of RPM is not fully clear to you -- its full potential opens up when it manages everything. But don't worry that much, it will not happen too soon. Re FHS, see the previous post.


Fahrvenugen, There is a difference from apps using OS/2 DLLs -- OS/2 DLLs are present on the system. Qt4 DLLs are not. Also take into account what Andreas said, he made a good point about OS2.INI which I didn't mention.

I understood your network share usage pattern correctly. I know all the stuff you mentioned, I did things like WSoD myself (I worked in a school as a sysadmin in the past; pupils are very aggressive users so I learned lots of stuff from there). While you may actually make this solution work in FHS pretty well (by redirecting /usr and /etc to a network share), this doesn't give you many benefits compared to the native RPM way where you may easily get the same "automated distribution" effect by installing/updating the necessary software from the user's logon script with a few simple yum commands. However, RPM, in turn, will give you a lot of benefit here because running the software from the hard disk is simply much faster than from a network share.

Pete, what you said about changing paths in OS2.INI when applications are dragged to different folders, is a fairy tale.

Andi

Just installed rpm/yum. As my applications usually are on P: I set unixroot=P: (wpi installer does not like slash or backslash after drive so be aware to set your unixroot without that). After installing yum there are 5 new directories at P:. bin, etc, tmp, usr, var. Don't understand why tmp was created cause I've %TMP%=T:\TEMP anyway. etc seems to be not necessary too cause there is %ETC%=D:\MPTN\ETC anyway. Moreover I think etc and var should be better on my data volume on E:\ and not on the applications volume. But leave it for now. Have to look if this can be corrected later. All in all it's about 180MB in 5 directories. Currently on P: there are about 14GB and more than 260 directories at root level. So I've no problem with that few additional MBs and dirs.

Here we go, let's install some applications. But yum list leads to -
{0}[d:\] yum list
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   dlopen rc=2 extra=PYTHON25

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
2.6.5 (r265:79063, Jan  4 2011, 13:06:36)
[GCC 4.4.4]

If you cannot solve this problem yourself, please go to
the yum faq at:
  http://yum.baseurl.org/wiki/Faq

Although the error message points to the problem, for a normal user without online chat with Dimitry ;) it maybe not that easy to resolve this. I miss the statement in the readme that you should remove all references to python like SET PYTHONHOME=p:/python25 in your config.sys prior to installing rpm/yum. After that it works as designed. Of course this may influence all your current python applications cause rpm/yum installs a newer python version. But for me I'm sure the newer python is compatible with all my python code. So no real problem here for me.

A few days later I wanted to install something new with yum. yum list available |more gives a list of available packages. Hint, it's more comfortable to read if you set more than 80 columns before (f.i. mode co81,99). Of course you can redirect the list to a file if you prefer. yum install exceptq starts to install exceptq. A long list of packages for update appears and yum asked for downloading 27MB. After accepted initially I interrupted the update process. I thought there must be something wrong cause exceptq can't be 27MB in size. Checking some packages I see there were a lot of changes in the repository. Updates of ash, coreutils... and so one. Seems there were some developers rather busy. So yum/rpm is correct in updating this packages. Although I do not understand why this all is necessary for exceptq, I trust in the packager of excepq knowing it better than me. And I understand from the developers point of view it's much easier to support a user when you know the user have installed the correct/latest utilities which may influence your software. So it makes sense to keep some core utilities at a current level. Remember on other operating systems it's common practice since years to force users to install the latest service packs before the get any support or before he can install some new software. This is not to bother users but it became impossible to support users with complex applications without keeping their environment up to date. I know especially eCS users do not like to give away even a small piece of control over there system. But we have to accept this when we want to use complex ported software I think. So take it or leave it. No problem when someone wants to stay f.i. with Warp 4. But do not bash the people who work on eCS and can not support your W4 system then. Same here. So firing up again yum install exceptq and yes, rpm is smart enough to download only the missing files from the previously interrupted installation. This is also true when the network connection to the rpm server fails during an install attempt which was the case here too. rpm takes care of that and knows if it have to download something or not. Very smart. I start to like it :)

Of course there are some unaesthetic aspects with this new rpm way for updating your system. F.i. yum install unzip installs the (nearly) same unzip version I still had on my system just in another directory. But he, even after a plain new eCS install I had 2 unzip.exe versions on my system.

[d:\] which -as unzip.exe
   1: 08/27/11 11:38:34     82676  p:/usr/bin/unzip.exe
   2: 05/30/10 10:37:14    136647  p:/util/unzip.exe
   3: 05/23/08 15:40:08    147507  d:/ecs/bin/unzip.exe

Now I've 3 and I can safely delete the older 2 cause I'm sure rpm takes care of the latest one with all its dependencies. I do not need to take care by myself if the right one is in the PATH and the correct libc is in libpath cause rpm set the path so that it's version will taken by default and checks the dependency. And as long as the rpm repository is kept up to date it's very easy to keep my system up to date too. After playing around a little bit with yum/rpm I'm think I will like it. Boys nice job what you've done. A big THANK YOU. Thinking about the troubles I had with various software, setting the environment correctly and manually check the dependencies, I know there's a big chance for rpm to makes these mess a little easier to handle in the future. Please keep the rpm repository up to date and fill it with new applications.

What's left to do for me is to check how to handle a local repository. I want to download the same software only once for all eCS systems I have. Another thing is to check how rpm handles the situation that my application volume usually on P: is the app volume for different eCS installations on the same system. Does rpm know that there's nothing to install beside the config.sys entries when booting from the maintenance partition? Will check as soon as time permits.

Again, thank you for doing all the great work to keep eCS alive. And if you think it's easier to port, distribute and support software the rpm/yum way, and I'm sure it is, just keep on going that track. And to all participants at this thread, please try to keep emotions low and do not attack personally. This should be a discussion about pro and cons of a way how to make new apps available to the community. Not about personal reservations or language barriers....

Regards,
Andreas

Btw, in the readme you can see how much ahead of time the rpm/yum porters are :)
HISTORY
1.3 - 13 Jan 2012