• 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

Poll: What is the height of RPM barrier?

Started by djcaetano, 2012.01.31, 16:30:49

Previous topic - Next topic

Andi

As much as understand the wish for 'OS/2 aware apps' and 'OS/2 aware installers' it was told to us numerous times that there is simply lack of developers who are willing to write these apps, installers, pack apps for different installers..... As long as no one stands up who is willing to do the work the users can whining again and again. It would not happen.

Some people work hard to get apps from *nix like platforms running on eCS. Each day they face the problems with these apps which are not designed to work on eCS. Workarounds, fixes and new ports are produced so eCS is still usable for some of us these days. But *nix apps expect some environment which exists on every *nix system anyway. If you want these *nix apps to run on eCS you have to either -

1) gave them these minimum environment. yum/rpm is a convenient way to assure this and minimizes needed support by the porters.
2) unpack the rpm package, add all dependencies, write an installation how-to and repack all into another format you like AND support the users which constantly ignore libpath/libpathstric settings and dll requirements
3) port the app by yourself and patch all these places where some environment is expected but does not exist on eCS and do this boring task again and again with every new version on for every new app you like to port
4) write the needed app by yourself as full OS/2 aware app and ignore the offer of using the rpms other free time developers kindly share with us

We are living in a free (mostly) world and you can choose what you want to install or not. You can choose to take what someone else offers to you for free or decline. But constantly ignoring the arguments from people who know much better what they are talking about cause the do this work day by day is some kind of foolish. If you don't like rpm/yum don't use it. But do not bitch about the developers and porters. And do not think you know how things work or should work with big *nix apps only when you've managed to bundle some simple apps into a warpin package. Accept the fact that others work the way they like and think its makes sense. If you think things have to be done in another way then prove it. Port and pack what you like and share it the way you like.



jep

#16
Exactly, it's very good that there's a rpm/yum engine for installation that now can handle all *nix applications in a convenient way for the eCS platform that also can provide developers with a useful tool to pack files for installation.

Should eCS rely on several installers? ok.
How do you feel about several installer back end engines and one gui?

//Jan-Erik

CDRWSel

The odd in *nix applications!
These applications often change default parameter value, or change parameter names etc...
Backward compatibility not garanty

All is done to generate many work to always update other tools using these *nix appl
Only a few limited type of open source (*nix) appl are allowed on high sensitive production systems. Generaly openPGP, openSSH (tools providing security)...   

Reduce RPM/YUM installer size to a max size between 2 and 4MB 
Option should allow to use strict respect of *nix path or user specified installation path (use of pathwriter)

Mike

There is some difference in porting an application and to install the application be the end user. Its hard to understand why we loose the ability to have the flexibility of  installing an application.  Why we need hard coded pathes? There is no technical reason todo so. I like when the install reads the system settings and use these and not the other way around.  ClamAV worked ok mostly before it was transformed to RPM.  Go figure...

Paul Smedley

Quote from: Mike on 2012.02.19, 20:09:25
Why we need hard coded pathes? There is no technical reason todo so.

Sorry, but the above displays a total lack of understanding of what's required to port an application to OS/2.

Unix apps _expect_ hardcoded paths - as on unix, _everything_ is in /usr

Depending on the app, it can be a huge amount of work to make the app flexible enough to handle being installed anywhere...

abwillis

Quote from: Paul Smedley on 2012.02.20, 10:24:10
Quote from: Mike on 2012.02.19, 20:09:25
Why we need hard coded pathes? There is no technical reason todo so.

Sorry, but the above displays a total lack of understanding of what's required to port an application to OS/2.

Unix apps _expect_ hardcoded paths - as on unix, _everything_ is in /usr

Depending on the app, it can be a huge amount of work to make the app flexible enough to handle being installed anywhere...
Consider... if Linux were as flexible as OS/2 then likely the community hanging in with OS/2 would have switched over to Linux.  I use Linux at work and while I prefer using it to Windows it lacks the flexibility and ease of use of OS/2.  Everything gets dumped wherever it is built for and wherever RPM dumps it is where it and good luck finding it if you don't know the executable name or have an icon installed by RPM because some things are dumped under /usr others under /opt and rarely some other random dumping ground.  The semi-myth is that you can do anything in Linux.  That is true if you are a hardcore programmer, otherwise it is a right pain in the rear to do much customization at all.

mmarquardt

My personal experience with rpm/yum is trying to install odin 0.8.2 with rpm/yum.  I could not get it to work, and it seemed very awkward to use.  If a linux package system is to be used, what about considering a debian (deb) system?  It seems fairly easy to use.  WarpIn seems quite easy to use and usually works.  Why complicate things with a more complicated installation system.  Strive to make things easier for the general user.

Paul Smedley

Quote from: abwillis on 2012.02.20, 18:12:26
Quote from: Paul Smedley on 2012.02.20, 10:24:10
Quote from: Mike on 2012.02.19, 20:09:25
Why we need hard coded pathes? There is no technical reason todo so.

Sorry, but the above displays a total lack of understanding of what's required to port an application to OS/2.

Unix apps _expect_ hardcoded paths - as on unix, _everything_ is in /usr

Depending on the app, it can be a huge amount of work to make the app flexible enough to handle being installed anywhere...
Consider... if Linux were as flexible as OS/2 then likely the community hanging in with OS/2 would have switched over to Linux.  I use Linux at work and while I prefer using it to Windows it lacks the flexibility and ease of use of OS/2.  Everything gets dumped wherever it is built for and wherever RPM dumps it is where it and good luck finding it if you don't know the executable name or have an icon installed by RPM because some things are dumped under /usr others under /opt and rarely some other random dumping ground.  The semi-myth is that you can do anything in Linux.  That is true if you are a hardcore programmer, otherwise it is a right pain in the rear to do much customization at all.

Andy - please understand - I'm not ADVOCATING the unix file system layout, just pointing out that fixing a ported app to NOT rely on it is non-trivial....

abwillis

Quote from: Paul Smedley on 2012.02.21, 10:05:17
Quote from: abwillis on 2012.02.20, 18:12:26
Quote from: Paul Smedley on 2012.02.20, 10:24:10
Quote from: Mike on 2012.02.19, 20:09:25
Why we need hard coded pathes? There is no technical reason todo so.

Sorry, but the above displays a total lack of understanding of what's required to port an application to OS/2.

Unix apps _expect_ hardcoded paths - as on unix, _everything_ is in /usr

Depending on the app, it can be a huge amount of work to make the app flexible enough to handle being installed anywhere...
Consider... if Linux were as flexible as OS/2 then likely the community hanging in with OS/2 would have switched over to Linux.  I use Linux at work and while I prefer using it to Windows it lacks the flexibility and ease of use of OS/2.  Everything gets dumped wherever it is built for and wherever RPM dumps it is where it and good luck finding it if you don't know the executable name or have an icon installed by RPM because some things are dumped under /usr others under /opt and rarely some other random dumping ground.  The semi-myth is that you can do anything in Linux.  That is true if you are a hardcore programmer, otherwise it is a right pain in the rear to do much customization at all.

Andy - please understand - I'm not ADVOCATING the unix file system layout, just pointing out that fixing a ported app to NOT rely on it is non-trivial....
My point was to point out the same thing... what I had meant was that as Linux is not flexible, neither are the applications so that even pointing to other locations is non-trivial.