Author Topic: Non-yum/rpm vs. ordinary (?) eCS  (Read 15843 times)

agena

  • Guest
Non-yum/rpm vs. ordinary (?) eCS
« on: April 26, 2015, 11:53:39 am »
Dear Ladies and Gentlemen,

this weekend, a very kind eCS user informed me that there were a difference between standard
and yum/rpm based Warpin installers.

I thought that OS/2 - eCS and NT were siblings so that any DLL linking/path problems experienced
on UNIX-based systems did not happen to us ?

Alex

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Non-yum/rpm vs. ordinary (?) eCS
« Reply #1 on: April 26, 2015, 05:22:16 pm »
Can you be more specific? Warpin and RPM/YUM are just 2 different ways to install stuff and resolve dependencies as far as I know.
Some stuff is ported to use %UNIXROOT% instead of x: though to be more portable.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: Non-yum/rpm vs. ordinary (?) eCS
« Reply #2 on: April 26, 2015, 06:30:36 pm »
Quote
this weekend, a very kind eCS user informed me that there were a difference between standard
and yum/rpm based Warpin installers.

WarpIn is a native OS/2 (AKA eCS) programming package installer. RPM is a packaging method that YUM uses to install, and track, programming packages (which also includes DLLs). RPM and YUM are ported from the *NIX world. Each has it's own advantages, and disadvantages. Some discussion can be found in the OS2world forums.

Quote
I thought that OS/2 - eCS and NT were siblings so that any DLL linking/path problems experienced
on UNIX-based systems did not happen to us ?

More, or less, true, but each method has it's own advantages, and problems. The main problem, that we have today, is that those who are porting *NIX programs to run in OS/2 don't want to spend the time to find all of the places where *NIX type DLL linking is used in the programs, and convert them to OS/2 type linking,  so they have decided to make a *NIX type of directory structure, with specific rules, to use with OS/2. That is essentially not compatible with the original OS/2 linking methods, but it does work, if you follow their rules. The result is what is known as "DLL HELL", if you break even one of the rules that the *NIX setup requires.

*NIX assumes that there is only ONE place, where all DLLs reside. By extension, that means that it is not possible to have more than one copy of any specific file name. That means that a user doesn't have to worry about down level, or duplicate, DLLs. One of the ways that *NIX updates such things, is by using RPM/YUM (although it seems that most distributions are moving on to something better). If you install RPM/YUM when you first install eCS, and NEVER use anything else to update, or install, anything, you will probably not have too much trouble. However, RPM/YUM does not install everything, so the user needs to use another method to install things. IF the user knows about the *NIX directory structure, and correctly uses that, they are likely to avoid most of the potential problems. Most OS/2 users have no idea what that is all about, so they almost always mess it up, and that will, eventually, cause trouble, especially if RPM/YUM is installed after the fact.

Some things that I have learned while testing the Arca Noae package installer (currently known as Yumie):

RPM and YUM work okay, when they work. It has been obvious that they do not always work properly. Yumie is only as good as YUM, and fixing problems with YUM can be a PITA.

An average user had better stick to the RPM release repository, or they are likely to have serious problems that can take some effort to figure out, and fix.

One "problem" with the release repository is that it can take MONTHS for new things to show up (also true of the experimental repository, but it is usually closer to being current).

Yumie is supposed to handle WarpIn packages, as well as RPM packages. So far, the WarpIn part is in early development. Far too much time has been required to try to work around YUM problems, so it hasn't been done yet.

The old RPM/YUM, installed by WarpIn, has a serious problem. Apparently, most users (including me), assumed that one should always use the YUM console to do updates. WRONG!. That uses a temporary sub set of YUM to get the current YUM package installed. The instructions do indicate that you can uninstall the WarpIn package, but it is not clear that you really should uninstall it (which also removes the YUM console). If you (correctly) use a normal command line to run YUM, it will work as well as it ever does. If you use the YUM console window, it will continue to use the old, temporary, installation, with down level software, and that causes problems. If you installed RPM/YUM with the eCS installer, it should work properly (but seems to break often).

Some things that you can do to prepare for the future:

Make sure that there is only ONE location where you keep "system" DLLs. By "system DLLs", i mean those that are used by more than one program (LIBC, GCC, and many others). This is complicated because eCS has added a new DLL directory where it keeps those things. When you add RPM/YUM, it makes another one, and takes no steps to remove duplicate (usually down level) DLLs from the old locations. Now, you have a problem if the wrong DLL gets used first, for any reason. The program that loads it will probably work, but if you then try to load a program that requires a later level, it isn't going to work (more likely, only one feature of the program won't work). If the later level DLL gets loaded first, both programs will work.

Look on your system for duplicate DLLs that may possibly get loaded. They don't necessarily need to be in LIBPATH. REMOVE them. Some programs were (incorrectly) packaged with DLLs, as a convenience to the user when they were distributed, and those do not get updated if they are not in the proper place. PTHREAD and MMAP are common.

Some users thought they were smart by moving "system" DLLs into "the only program that uses it" directory (Firefox, for instance). Now they installed a new program that uses one of those DLLs, and it won't work, so they finally figure out that it needs a DLL that is in Firefox. Their answer was to add Firefox to the LIBPATH. Then, they wonder why installing a new Firefox wiped out the DLL that wasn't supposed to be there in the first place.

Anyway, users should track those things down, and get rid of them. The complication is, that programs also use their own DLLs, which SHOULD be in the specific programs directory (and NOT in the single location used by "system" DLLs, although that should work okay).

You should also be aware, that QT programs store the location of the DLLs (and other things) in %HOME%\.config\Trolltech.ini. If anything in that file gets changed, you need to delete the file (it will be recreated). That is a common cause of QPDFView failing to find the PDF, DJVU, or PS, DLLs, even though they are where they should be found.

So, welcome to DLL HELL.

Highwinder

  • Guest
Re: Non-yum/rpm vs. ordinary (?) eCS
« Reply #3 on: October 06, 2017, 02:02:37 am »
And here we have the second reason why I'm sticking with WarpIn and not going the RPM/YUM route, the first being my unwillingness to shut the door on older versions of OS/2 just for new installer with a new set of problems.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Non-yum/rpm vs. ordinary (?) eCS
« Reply #4 on: October 06, 2017, 03:04:44 am »
And here we have the second reason why I'm sticking with WarpIn and not going the RPM/YUM route, the first being my unwillingness to shut the door on older versions of OS/2 just for new installer with a new set of problems.

RPM/YUM are not restricted to certain versions of OS/2, they work just the same on Warp v4 as ArcaOS and Arca Noae have made the Arca Noae Package Manager (ANPM) freely available.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: Non-yum/rpm vs. ordinary (?) eCS
« Reply #5 on: October 06, 2017, 04:57:36 am »
I will admit, that I do NOT like RPM/YUM, at all, BUT, you are not going to survive in today's OS/2 world without it. It is just way too complicated to try to keep up manually. Of course, you do have the option to stop doing updates, but that will probably cause more problems than you might expect.

The Arca Noae Package Manager (ANPM) makes it a LOT easier to use RPM/YUM. I strongly recommend starting to use ANPM (RPM/YUM) when you install a new system, and don't look back. It can be a bit messy trying to add ANPM (RPM/YUM) to an old install, but it can be done, if you take the time to understand how RPM/YUM works. There is a new ANPM in the works, and it should help to avoid some of the dumb things that RPM/YUM can do to you.

RPM/YUM is never going to replace some of the WarpIN installers, and it won't replace some of the ZIP installers. What it will do, is save you many hours of messing around, trying to figure out what you need to do to make some modern programs (like Firefox) work properly. Today, I tried the new Firefox 45.9.0, which was installed using ANPM (RPM/YUM). It took about one minute, to install (with all of the required support), and it is working well, so far.

Joop

  • Hero Member
  • *****
  • Posts: 633
  • Karma: +5/-0
    • View Profile
Re: Non-yum/rpm vs. ordinary (?) eCS
« Reply #6 on: October 06, 2017, 05:22:44 pm »
The Arca Noae Package Manager (ANPM) makes it a LOT easier to use RPM/YUM. I strongly recommend starting to use ANPM (RPM/YUM) when you install a new system, and don't look back. It can be a bit messy trying to add ANPM (RPM/YUM) to an old install, but it can be done,
You say the right thing, when you install a new system. An old install like ECS1.2 its not to be advised to install. I didn't hear of a clean and right installation on ECS1.2Dutch. All did go with a lot of trouble. My system directory alone with dll's etc counts 14346 files. You don't set that right with those packages.
Today, I tried the new Firefox 45.9.0, which was installed using ANPM (RPM/YUM). It took about one minute, to install (with all of the required support), and it is working well, so far.
What's beyond me is that we have native archive programs to get a zip file. Why we have to use 7zip is not clear. The negative thing is that it is a ported nix program. Now I'm willing to install that, but after the download of 7zip you are confronted with the next problem. All documentation in the ported zip file are for nix systems, not a word about OS/2-eCS. The files in this distribution for OS/2-eCS are not the same as for nix systems. So the documentation fails because only nix files are mentioned. The next hurdle is that I have to translate everything into my language, most of the times that goes okay, but if things are not even mentioned in the English manual things get complicated.
I can understand that we port some programs from nix or even windows. But more and more I get the idea we just have to migrate to nix stuff. I have such a system, from Apple and that one sucks too. If you want data from program a to program b you have with Apple a real problem if they didn't thought about that possibility. Everything is only possible with wireless or something like that. Doing it by cable is just not possible. Just a few examples I experience.

ak120

  • Guest
Re: Non-yum/rpm vs. ordinary (?) eCS
« Reply #7 on: October 06, 2017, 09:32:14 pm »
And here we have the second reason why I'm sticking with WarpIn and not going the RPM/YUM route, the first being my unwillingness to shut the door on older versions of OS/2 just for new installer with a new set of problems.

RPM/YUM are not restricted to certain versions of OS/2, they work just the same on Warp v4 as ArcaOS and Arca Noae have made the Arca Noae Package Manager (ANPM) freely available.
You're talking about 3 different programs. Each of them has their own restrictions and dependencies. As ANPM requires a full YUM environment (and latest (O)REXX) I will focus on RPM and YUM. YUM requires python, which requires at least one of the later Warp 4 fixpaks and a huge amount of memory - additionally a quite recent 32-bit IP stack.
RPM alone ships only as a RPM package which makes it very complicated to deploy for stand-alone or non-IP connected systems. Because of the library requirements (klibc) it's quite impossible to use it with Warp 3 based systems or earlier.

ivan

  • Hero Member
  • *****
  • Posts: 1557
  • Karma: +17/-0
    • View Profile
Re: Non-yum/rpm vs. ordinary (?) eCS
« Reply #8 on: October 06, 2017, 10:52:04 pm »
Quote
What's beyond me is that we have native archive programs to get a zip file. Why we have to use 7zip is not clear. The negative thing is that it is a ported nix program. Now I'm willing to install that, but after the download of 7zip you are confronted with the next problem. All documentation in the ported zip file are for nix systems, not a word about OS/2-eCS. The files in this distribution for OS/2-eCS are not the same as for nix systems. So the documentation fails because only nix files are mentioned. The next hurdle is that I have to translate everything into my language, most of the times that goes okay, but if things are not even mentioned in the English manual things get complicated.
I can understand that we port some programs from nix or even windows. But more and more I get the idea we just have to migrate to nix stuff.

I can live with some ported things BUT there should be either a working man reader (forwards, backwards change text size etc.) or the man pages should be supplied as simple text files or PDF files if they require to keep the formatting.

I also agree with Joop.  They ported 7zip as a command line program, which I assume it is in the nix world, but we usually work in a GUI environment so would expect a GUI front end for both zipping and unzipping aka the windows version of 7z.

rant over for tonight.

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: Non-yum/rpm vs. ordinary (?) eCS
« Reply #9 on: October 07, 2017, 02:24:02 am »
Hi ivan

There is a gui for 7z files supplied with ArcaOS called Archive Tool which is probably based on Zippy, see http://en.ecomstation.ru/projects/zippy/


Regards

Pete

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: Non-yum/rpm vs. ordinary (?) eCS
« Reply #10 on: October 07, 2017, 09:10:52 am »
Even "arcview.exe" that comes with eComStation supports 7z files.
You just need to create an association. The easiest way is to use XWP to create a file type say "7z Archive", tie that to file extension .7z and then to select "arcview.exe" as the handling program.
That will at least allow you to view the file contents but I am pretty confident it will also support extraction.

xynixme

  • Guest
Re: Non-yum/rpm vs. ordinary (?) eCS
« Reply #11 on: October 07, 2017, 11:14:33 am »
I also agree with Joop. They ported 7zip as a command line program, which I assume it is in the nix world, but we usually work in a GUI environment so would expect a GUI front end for both zipping and unzipping aka the windows version of 7z.

</silence>And, as usual, couldn't be bothered to release an eCS 2.x'ish 7-zip update package for Joop's eCS 1.2 (just files, no possibly introduced *.*.*.*.*.7Z WPS objects)...<silence>
« Last Edit: October 07, 2017, 11:21:37 am by AndrĂ© Heldoorn »

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4711
  • Karma: +41/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: Non-yum/rpm vs. ordinary (?) eCS
« Reply #12 on: October 07, 2017, 02:08:24 pm »
Hi

I also want to rant, but my dislike is only for FHS, which I think it is the worst of the Linux world. But beside FHS I'm fine with RPM/YUM and ANPM really helped with the lack of GUI for it.

But all the software ported from the *nix world to OS/2 is helpful to us. There is a lot of software that uses libraries like libc, pixman, cairo, SDL etc., and having that libraries ported to OS/2 make it easy for developers to also make ports (and even new software) to run (natively) under this platform. It is hard to find people with skill on the classic OS/2 API (CPI, Presentation Manager, SOM and WPS) today, so sticking strictly to that classic API will let us without a lot of modern applications. Maybe that's is why it is faster for an OS/2 developer (without money or an army of developers) to have the p7zip DLL ported instead of trying to adjust all *nix software ported to use a "classic API" zip tool.

And, about having the manual in my native language (Spanish) and a INF format, I prefer to have the application ported first and if I want a specif manual for the OS/2 platform I would help the developer to format it on a wiki or translate it so he/she did not spend time on that kind of tasks.

Having personal preferences for OS/2 1.x, 2.x, Warp 3 or Warp 4.0 is ok. But I think that a developer can not focus to port software to every version in time of the "Classic OS/2 API". With the limited resources that the community have I found it alright to focus on the 4.52 level of the API.

I think that is good today that developers have more choice under the OS/2 platform. They can develop with the "Classic OS/2 API" (which source code remains on IBM's basement) or they can use a "Open API" (which evolved over time) to create their applications on OS/2. Or they can even mix the two APIs :) . As users we have the benefits of both sides, OS/2 created with the "Classic OS/2 API" runs and newer applications (made with the "Open API") from the open source community are also available.

Regards
« Last Edit: October 07, 2017, 02:37:20 pm by Martin Iturbide »
Martin Iturbide
OS2World NewsMaster
... just share the dream.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Non-yum/rpm vs. ordinary (?) eCS
« Reply #13 on: October 07, 2017, 06:45:21 pm »
The main reason that I use 7z sometimes is it is much better at compressing then plain zip.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: Non-yum/rpm vs. ordinary (?) eCS
« Reply #14 on: October 07, 2017, 06:50:38 pm »
Quote
What's beyond me is that we have native archive programs to get a zip file. Why we have to use 7zip is not clear.

Well, for one thing, 7ZIP compresses better than ZIP. I see, typically, about 10% reduction in the archive file size. Not a big thing, until you start to upload a 2 GB dump file, or download a 1.3 GB file. I have a 2 GB dump file that compressed to about 850 MB, and the ArcaOS download file is about 1.3 GB, and the compressed size is about 900 MB. 7ZIP is just a new tool to do the same job, better, so why not use it?

7-ZIP is at HOBBES. ArcaOS has a GUI front end, which is also available elsewhere.