• 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

djcaetano

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

Pete

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



djcaetano

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

DougB

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.

diver

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

Pete

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




djcaetano

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

djcaetano

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

herwigb

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.
Kind regards,
HerwigB.

aschn

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

djcaetano

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. :)

RobertM

How about looking at how Android does it? Pretty painless.


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


CDRWSel

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.

Ben

#13

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:



  • IBM Installer
  • GenInstaller
  • Others
  • WarpIn - (already dealt with, but here it is again)
  • ZIP file

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


jep

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