OS2World OLD-STATIC-BACKUP Forum

WebSite Information => Article Discussions => Topic started by: djcaetano on 2012.01.31, 16:30:49

Title: Poll: What is the height of RPM barrier?
Post by: djcaetano on 2012.01.31, 16:30:49
http://www.os2world.com/content/view/21385/2/ (http://www.os2world.com/content/view/21385/2/)
QuotePosted by Eugene Gorbunoff - Friday, 27 January 2012


New poll. .. .

  I think RPM is not really a "definitive" barrier. It´s not that difficult, provided some additional software (non-existent at the moment). I believe many users are troubled because they feel they are loosing the control of their systems, leading to a lot of problems when something goes wrong (and they often do, and that´s the reason why I do not like Linux).

  Anyway, since "let´s get back to WarpIn" is a "no-go", lets stick to the user interface problem: RPM/YUM user interface is poor. I often have to copy/paste yum commands from Wiki pages to install packages, and this is not something I would call "intuitive".
  RPM/YUM would be a lot more interesting with a eCoMarket-like interface. Even more interesting if a daemon stay running and verifying now and then (once a day?) if there are updates to the installed packages - and ASK the user if he wants to install them.

   Another interesting eCoMarket feature is keeping a local copy of installed packages, so this local repository could be burn to a CD and used in future installations when on non-internet connected computers.

   RPM/YUM for OS/2 should be provided with a tool like WarpIn Package Manager, which can easily show *every* file installed in *which* folder and *what* icons were created by each installed package.
   
   I liked a lot RPM/YUM do know WarpIn database (when I tried to install new Odin I received the message "Hey, uninstall current ODIN installed by warpin first!"... but this could be improved with a dialog "Odin was previously installed with WarpIn. Uninstall it first? [OK] [Abort]". Also, it would be nice if the "rpm/yum" updater daemon checked what WarpIn packages are already available in RPM format and asked the user which they would like to migrate to YUM/RPM and do it silently.

   I know it is impossible to do it for all applications ever provided in WarpIn format, but this should be done at least for more popular WarpIn library and application packages.

  Also, a simple guide of HOW one could package an application using RPM/YUM (or even how one can convert a WarpIn package script to RPM/YUM) would be nice too... the many developers adopt RPM/YUM, the better will be its acceptance (keep in mind how hard is to keep track of all gcc*.dll and libc*.dll these days).

   Well, these are my remarks about the topic. I understand the reasons why developers would like to move to RPM/YUM and UNIX directory structure... OTOH, I do understand why long time die-hard OS/2 users do not want to use a tool (whatever it is) which makes their beloved operating system as clumsy as a Linux distribution.

   Regards,

   DJC
Title: Re: Poll: What is the height of RPM barrier?
Post by: Pete on 2012.01.31, 16:42:59
Hi DJC

Sorry but I'm not in favour of yum/rpm myself.

If I wanted to use yum/rpm then I would be using 1 of the *nix distributions rather than eCS.

Also the only thing that seems to make it difficult to keep track of gcc and libc dll packages is the lack of information provided with the software that requires them.


Regards

Pete


Title: Re: Poll: What is the height of RPM barrier?
Post by: djcaetano on 2012.01.31, 17:04:49
Quote from: Pete on 2012.01.31, 16:42:59
Sorry but I'm not in favour of yum/rpm myself.

  I am not also. But I am being realistic. Those who port software will use RPM/YUM. So...

Quote from: Pete on 2012.01.31, 16:42:59
Also the only thing that seems to make it difficult to keep track of gcc and libc dll packages is the lack of information provided with the software that requires them.

    No, there is also incompatible libc versions, there are programs that are packaged with their own versions of (sometimes buggy) libc which bring problems to other programs if LIBPATH statement is not correctly ordered... etc.
    Most cases of "this program works here but not there" are examples of this situation.

    The "root" of the problem is the need of ported software. We should never need to use ported software on a day-by-day basis... But they are what we have to work with (almost no native software is developed nowadays) and make them understand "what OS/2 is" and "how we like to work" is very difficult (and demands lots of work)... We do not have the human resources to do it. So, the idea is reduce the porting difficulties, so more software can be ported and more bugs can be solved in a reasonable amount of time. The number of OS/2 developers is falling year by year... we should keep that in mind.

     I would like to REMARK: I *do not like* RPM/YUM... the same way I do not like using CDRECORD or FFMPEG. But with proper user interfaces (DVD Toys and AVxCAT for instance) they are quite useable. I *hate* UNIX file structure. But I also hate the need to add dozens of paths to LIBPATH and trying to discover why this ported program is not working in my machine if it works on every other machine in the world.

     Between using RPM/YUM or not using updated software at all, one has to choose between bad and the worst. In that case, I choose bad (RPM/YUM). It has a sour taste, but it is better than famine.

    Regards,

    DJC
Title: Re: Poll: What is the height of RPM barrier?
Post by: DougB on 2012.01.31, 19:23:40
Quote"let´s get back to WarpIn" is a "no-go"

Why? It works far better than RPM/YUM ever will. Reinventing the wheel, by cutting a slice off of a tree trunk, is not a smart thing to do. Eventually, it could be turned into something that will work properly (5, perhaps 10, years?), but so far, I am not even sure that they have the concept of adding an axle to the tree trunk. Be assured, that there is very little that RPM/YUM can do (or ever will do) that WarpIn cannot already do, and WarpIn gives the user, and the program packager, a lot more control than RPM/YUM ever will.

FWIW, I intend to use whatever packages are packaged in (preferably) WarpIn, or ZIP files, and those that do not get packaged that way just won't be used. They also won't be used if they won't work in the eCS way of doing things. The prime example is ClamAV. That hasn't worked right since the first release that was put into RPM/YUM, even when it is packaged by WarpIn. The port has been made to fit in the round hole of linux, and it doesn't work in the square hole of eCS. I am not sure if that was done on purpose, to promote RPM/YUM, or if Yuri just got too lazy to make it truly compatible with eCS (probably too busy trying to make RPM/YUM work). In either case, ClamAV will work, but only under very strict circumstances. I cannot make it work with drag and drop, or with a batch file, and I cannot make it work by associating it with files, or adding it to the folder, or drive icon menus.  I have also not been able to get RPM/YUM to properly install ClamAV on my test machine. It did not make icons, and when I went looking for the program so I could make my own, bits and pieces of ClamAV were spread all over the pseudo linux directory structure. Not only that, but SAMBA quit working after I installed RPM/YUM. I suspect that many other programs (anything that uses UNIXROOT) would also have problems. Fortunately, DragText has a feature to set environment variables  for programs like that.

RPM/YUM is a HUGE step backward, and I, for one, will not accept that.
Title: Re: Poll: What is the height of RPM barrier?
Post by: diver on 2012.01.31, 19:51:20
Then beginn to Sponsor Money. And i mean a lot Money. You have absolute No idea What it takes to Port an App. to write One from scratch need Even more. its just a fact a lot of us Do it in sparetime . And to short on those Who Do something will Not bring you anywhere.
Title: Re: Poll: What is the height of RPM barrier?
Post by: Pete on 2012.01.31, 19:55:18
Hi DJC

I seem to recall from a previous yum/rpm discussion on this site that ported software will continue to be offered in zip packages as well as yum/rpm - and that seems to be the case so far. I also seem to recall there was talk of repacking into Warpin packages as well.

As long as that happens then I will continue to use either zip/Warpin packages.

If porters decide to stop supplying zip/Warpin packages then I will have to rethink my choice of operating system.

I'm not sure what you are referring to when you say "I also hate the need to add dozens of paths to LIBPATH" but maybe we just use different software...

I don't think that I currently have any software that includes specific gcc/libc packages - certainly lots that requires gcc/libc packages and they all seem to be working fine. However, I have seen mention in a couple of ngs that some older software requiring libc063.dll does not work with the version supplied with libc064 package. Not sure what software is involved but I either have not used it(those) recently or do not have the(those) package(s) installed.

A simple way of avoiding gcc/libc*.dll hell is to decide to stick all those dll files into 1 directory. On an eCS system that should be [BootDrive]:\ecs\dll and for OS/2 I suggest [BootDrive]:\os2\dll. That directory should be in the LibPath - fairly close to the start of the line.

Another thought: Any time you update gcc/libc dll files you should reboot - just to make sure that the file(s) replaced are not already in memory which will cause problems if you try to run an app requiring the updated file(s).


No, Sorry but I am not convinced of the necessity of yum/rpm at all.


Regards

Pete



Title: Re: Poll: What is the height of RPM barrier?
Post by: djcaetano on 2012.01.31, 20:05:43
Quote from: DougB on 2012.01.31, 19:23:40
RPM/YUM is a HUGE step backward, and I, for one, will not accept that.

WarpIn is a no-go because many developers will not use it anymore. This may be an unfortunate decision, but it seems I will need to live with it.
What I am trying to point out is what it makes it bad... and CAN be corrected. I was not intending to start "we like" x "we do not like" discussion again.

Anyway, using RPM in a plain clean install (and installing with WarpIn only what is missing) brought no problems and everything installed through RPM *and* WarpIn is working as it should, without conflicts. Besides the messy Linux directory structure and the "you must know package names" thing, I really had no problem with RPM.
OTOH, installing the YUM/RPM package on a system with lots of software already installed *did* revealed a lot of problems, mostly with duplicate and incompatible DLL versions.

Regards,

DJC
Title: Re: Poll: What is the height of RPM barrier?
Post by: djcaetano on 2012.01.31, 20:26:32
Quote from: Pete on 2012.01.31, 19:55:18
I seem to recall from a previous yum/rpm discussion on this site that ported software will continue to be offered in zip packages as well as yum/rpm - and that seems to be the case so far. I also seem to recall there was talk of repacking into Warpin packages as well.

   ZIP yes. But I do not like to mess with ZIP files, unless really needed. :)
  About WarpIn, unfortunately it will depend on third parts (besides the developers).

Quote from: Pete on 2012.01.31, 19:55:18
As long as that happens then I will continue to use either zip/Warpin packages.
If porters decide to stop supplying zip/Warpin packages then I will have to rethink my choice of operating system.

  I was thinking that way. But I believe I was overreacting. WarpIn is a way better solution for the end-user, but I ported some software back in the day... and tried to port a lot of different ones. What I know is:

   a) It is *a lot* of work...!
   b) It is almost impossible to get the source maintainer to include our modifications (or hacks) to make it work on OS/2 (which generates a lot of double work each time a new version comes out).

Quote from: Pete on 2012.01.31, 19:55:18
I'm not sure what you are referring to when you say "I also hate the need to add dozens of paths to LIBPATH" but maybe we just use different software...
I don't think that I currently have any software that includes specific gcc/libc packages - certainly lots that requires gcc/libc packages and they all seem to be working fine. However, I have seen mention in a couple of ngs that some older software requiring libc063.dll does not work with the version supplied with libc064 package. Not sure what software is involved but I either have not used it(those) recently or do not have the(those) package(s) installed.

   WarpIn requires you have some discipline to install libraries always at the same place (no one seems to agree where each piece of software should be installed). Since some packages install them on eCS/DLL, others on OS2/DLL (and so on), this *may* generate a lot of duplicity. Sometimes a library is updated, sometimes an old library is provided as a stub to a new one... this brings problems.
   About adding things to PATH/LIBPATH, think on VLC... think on SDL, think on FFMPEG, think on CDRECORD... just to name a few. Ok, one can put all of them in the same /DLL and /BIN directory... but then, we will be using Linux path structure, with different path names. What is the point against RPM/YUM in this case?

Quote from: Pete on 2012.01.31, 19:55:18
A simple way of avoiding gcc/libc*.dll hell is to decide to stick all those dll files into 1 directory. On an eCS system that should be [BootDrive]:\ecs\dll and for OS/2 I suggest [BootDrive]:\os2\dll. That directory should be in the LibPath - fairly close to the start of the line.

  Just as I said above...

Quote from: Pete on 2012.01.31, 19:55:18
Another thought: Any time you update gcc/libc dll files you should reboot - just to make sure that the file(s) replaced are not already in memory which will cause problems if you try to run an app requiring the updated file(s).
No, Sorry but I am not convinced of the necessity of yum/rpm at all.

  I am sorry I am such a BAD English writer. I did not said it is necessary. I said "if you can't beat them, join them".
  Instead of moan and do all the hard work (getting the ZIP file and so on), I am giving YUM/RPM guys a chance. And I am complaining what I think is missing.

  You are fighting the wrong guy. I am not advocating RPM/YUM. I am just saying I realized it is not that horrendous thing at all. It is worse than WarpIn from a user point of view? In some aspects, YES. But it is not (for me) a reason to depart from OS/2. And if I will have to live with RPM/YUM, then I want the developers to know what I think is missing.

   Regards,

   DJC
Title: Re: Poll: What is the height of RPM barrier?
Post by: herwigb on 2012.01.31, 20:28:17
I prefer to have 2 actively maintained installers - WarpIN and RPM/YUM. I do remember the flamewars about WarpIN compared to whatever and that WarpIN sucked big time.

Now, without any significant changes in years WarpIN is great suddenly? Sometimes things like that put a big grin into my face and make sure I don't take things too serious.

And to make one thing clear: When I first put my hands on RPM/YUM it did not work properly, I found it ugly and did not like it at all. BUT after some trials and tests I have to acknowledge: Its feature set is far better than the one from WarpIN and be assured: RPM/YUM can and will be sexy as well.

However: The sheer existence of RPM/YUM has lead to a significant enhancement for WarpIN already: Recent WarpIN archives (Samba Client, Lucide) come with a check to find out whether a DLL or EXE file exists on a system without having been installed by WarpIN. It is Rexx- based but very easy to integrate into existing WarpIN archives. And guess who provided it: It is based upon code from Dmitriy, was enforced by Silvan (and myself lend a little hand). Anyway: This is an important enhancement for WarpIN archives - the biggest one in years!

I am a WarpIN-Guy (and quite likely will always be one), neverthelesse it is a good thing RPM/YUM was ported because it is an alternative way to get things onto your machine in a clean way.
Title: Re: Poll: What is the height of RPM barrier?
Post by: aschn on 2012.01.31, 22:45:16
Quote from: djcaetano on 2012.01.31, 20:26:32
WarpIn requires you have some discipline to install libraries always at the same place (no one seems to agree where each piece of software should be installed).

No, it's not WarpIN, it depend on the packagers. WarpIN itself is (unfortunately) far too dump to manage dependencies as well as we need it in our special OS/2 world of having files installed in user-selectable paths. It all depends on what the package creator adds as logic to the REXX part of the WarpIN installation.

Quote from: djcaetano on 2012.01.31, 20:26:32
Since some packages install them on eCS/DLL, others on OS2/DLL (and so on), this *may* generate a lot of duplicity. Sometimes a library is updated, sometimes an old library is provided as a stub to a new one... this brings problems.
About adding things to PATH/LIBPATH, think on VLC... think on SDL, think on FFMPEG, think on CDRECORD... just to name a few. Ok, one can put all of them in the same /DLL and /BIN directory... but then, we will be using Linux path structure, with different path names. What is the point against RPM/YUM in this case?

Let me guess the answer: nothing.

Quote from: djcaetano on 2012.01.31, 20:26:32
You are fighting the wrong guy. I am not advocating RPM/YUM. I am just saying I realized it is not that horrendous thing at all. It is worse than WarpIn from a user point of view? In some aspects, YES. But it is not (for me) a reason to depart from OS/2. And if I will have to live with RPM/YUM, then I want the developers to know what I think is missing.

I don't understand the excitement about YUM, RPM or WarpIN or not using them. If it works, we should be happy -- if not, just feed the bugtracker. I don't see any chance to avoid any of them.

My opinion: I see the reasons why porters of ix software switch to a system that eases the dist part. We (I'm more a user then a contributor/developer) should be happy if there's anything new available in these years at all. BTW: RPM/YUM works well for me. I can imagine how much work developers will save themselves by having made that change (from WarpIN or anything else to RPM/YUM).

BTW: There were no bigger tries to improve WarpIN in the last years, despite many ideas exist for that. WarpIN in its actual state is not too bad - but that's no reason to ignore the world outside and then not to choose the tool that fits to our needs the most. (Note that the YUM GUI still doesn't exist, but I'm sure it will come.)

Andreas
Title: Re: Poll: What is the height of RPM barrier?
Post by: djcaetano on 2012.02.01, 04:23:14
Quote from: aschn on 2012.01.31, 22:45:16
I don't understand the excitement about YUM, RPM or WarpIN or not using them. If it works, we should be happy -- if not, just feed the bugtracker. I don't see any chance to avoid any of them.
My opinion: I see the reasons why porters of ix software switch to a system that eases the dist part. We (I'm more a user then a contributor/developer) should be happy if there's anything new available in these years at all. BTW: RPM/YUM works well for me. I can imagine how much work developers will save themselves by having made that change (from WarpIN or anything else to RPM/YUM).

  Indeed, I do share your point of view. :)
Title: Re: Poll: What is the height of RPM barrier?
Post by: RobertM on 2012.02.01, 07:08:26
How about looking at how Android does it? Pretty painless.
Title: Re: Poll: What is the height of RPM barrier?
Post by: CDRWSel on 2012.02.01, 15:20:12
Quote from: Pete on 2012.01.31, 19:55:18
Hi DJC

I seem to recall from a previous yum/rpm discussion on this site that ported software will continue to be offered in zip packages as well as yum/rpm - and that seems to be the case so far. I also seem to recall there was talk of repacking into Warpin packages as well.

As long as that happens then I will continue to use either zip/Warpin packages.

Hi,
Just as information, until now, new ClamAV wasn't available as ZIP nor WPI package (e.g. v0.97.2), many additional dlls should be updated like mmap.dll, urpo.dll etc.. This was given as argument to only use RPM/YUM installer due other component have required upgrade or additional dlls are required to have clamav working...  (I tested the 0.97.2, added missing dlls but finally, always got an error message :-( )   ::)
 
Now, I was happy to get an email with a proposed different compiled ClamAV at 0.97.3 version as a small zip file only. (no unixroot required, nor additional Dlls except libc064). I did a test and it work great, tested it into a WPI and it is ok too... I say "Bravo" for this build.
Title: Re: Poll: What is the height of RPM barrier?
Post by: Ben on 2012.02.01, 15:49:41

Personally, the reasons that I use OS/2 are its ease of use, its functionality, and, (here are the relevant bits), it's ability to operate independently, (and other related privacy concerns), and it's total lack of nagware of any sort. I don't need reminders. I'm not a child. I had enough of that sh*t when I was a child. One of the benefits of being an adult male is that I do not have to tolerate those intrusions any more. Constant, redundant password requests fall into this category. They are ridiculous, inane, needless, redundant, easily fixed and stink of Operant Conditioning, (don't know what that is? You should. It's used on you every day).

And good riddance to it all. May it, (as a whole), never infect good, ol', OS/2.

Some may disagree and say otherwise. However, being reminded of new updates is nag, nag, nag!ware as far as I'm concerned and anyone that says otherwise has modified the meaning of the word in their own mind to accept the otherwise unacceptable; They are weak. Soft. Malleable. If I want/need an update, I'll look for it and install it myself. For updates and bug fixes are always a double-edged sword; It can save you, and it can wound you.

Also, if an installer splays bits and pieces of a product all over the system in a way that I cannot quickly and easily, find it and remove it, (or whatever), then that's a step towards Windows and Windows is metaphorical, xeno-estrogen-laced junkfood; For the simple-minded and weak; Not for me!

Now as options there have been a number of installers for OS/2. I cannot say if they will suite the purposes of the porters/programmers, for I am neither. What I can do though, is list some of the ones known to me.

I shall do so now:


Barring any workable auto-installer there is the "ZIP file option"; Simply dump it all in one directory and add the necessaries to the PATH statement(s). Not ideal, but there is only one significant problem that I can see; PATH statement enlargement. (Porn addicts: Don't confuse with the penis enlargement; They are not the same).

By "Others" there are lesser installers out there that have been used by OS/2 software companies over the years. I don't know if any of them are appropriate for any-or-all cases where installers are an issue, or if the source(s) is(are) even available. But ex-OS/2 software programmers have been known to be tracked down from time to time and thus, remain a consideration where no easy solution has been forth coming.

I know some of this has been covered before, but here I present it encapsulated, in one neatly wrapped package, not unlike an Xmas present, or for the children amongst you, in one big-and-swollen, gelatinous, teat for you to suck on, with pre-enlarged aureoles complete with elongated and pre-warmed, nipple!

That's my spiel for today.

Now I must go and kick the cat.



MEERRRROOOOWWW!!!! :o


That's it! I'm gone...

Title: Re: Poll: What is the height of RPM barrier?
Post by: jep on 2012.02.02, 12:00:37
Hello,

From a user point of view I'm mostly interested in that it's easy to use and allow me to be in charge, how it does it behind the curtain is not that interesting. Do we have to have x number of installers, can't we get one that does the work and therefore keep track of things and coordinate it right?

It would be nice if it's an eCS aware procedure that handle eCS-applications and wps/som/rexx etc. and reuse parts of the knowledge aquired from the work with WarpIn. I'd prefer if it's an integrated part of the wps that install applications. Please do note that rexx is a part of eComStation, as well and the scripting language in eComStation.

Some demand that apperance of everything should be "sparse", other that things has to be done to improve visiblity, apperance and info.
There's no conflict between the two, but more info doesn't mean differently bright colored buttons and random flashing animations.

//Jan-Erik
Title: Re: Poll: What is the height of RPM barrier?
Post by: Andi on 2012.02.02, 13:35:55
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.


Title: Re: Poll: What is the height of RPM barrier?
Post by: jep on 2012.02.02, 14:23:37
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
Title: Re: Poll: What is the height of RPM barrier?
Post by: CDRWSel on 2012.02.02, 16:34:36
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)
Title: Re: Poll: What is the height of RPM barrier?
Post by: Mike on 2012.02.19, 20:09:25
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...
Title: Re: Poll: What is the height of RPM barrier?
Post by: 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...
Title: Re: Poll: What is the height of RPM barrier?
Post by: 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.
Title: Re: Poll: What is the height of RPM barrier?
Post by: mmarquardt on 2012.02.21, 01:47:56
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.
Title: Re: Poll: What is the height of RPM barrier?
Post by: 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....
Title: Re: Poll: What is the height of RPM barrier?
Post by: abwillis on 2012.02.21, 19:10:14
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.