Author Topic: Arca Noae Package Manager Comments  (Read 6753 times)

Doug Bissett

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 53
  • Posts: 1313
    • View Profile
Re: Arca Noae Package Manager Comments
« Reply #15 on: January 20, 2016, 07:43:59 pm »
The main problem with trying to keep up with RPM/YUM, is that the required information is not available. The only way to do it is to decode the YUM updates files, then try to relate that to what you already have, and figure out what you need. If you enjoy spending hours of frustrating time trying to do that, be my guest.

RPM/YUM is a terrible program, but it does do all of that for you. The worst part is that you must depend on somebody building the packages properly, and updating the repositories correctly. The second worst part is that you need to do the proper commands to keep it all up to date. The best part is that YUM does decide what else is needed, as long as the package is built properly.

Then, the user has to use the command line, with obscure commands to do all of that. That is where Arca Noae Package Manger steps in. It knows the proper commands, and with a few mouse clicks it does what is needed. Unfortunately, it seems that YUM manages to invent new ways to screw up, so it is impossible for ANPM to manage errors properly. All it can do, is advise the user to report a problem to the appropriate place, and hope that is enough to get the problem fixed.

Unfortunately, those who do the porting have decided that this is the way that they will distribute their work. Like it or not, we, the users, are given little choice but to follow, do a LOT of manual work, or quit using ported programs.

Quote
BTW, yum/rpm installs a lot more than just some DLLs.

Yes it does, and that can also cause problems, when a user doesn't realize it (and you probably won't). Suddenly, for no apparent reason, something like SORT.EXE can change from the old IBM version, to the new *NIX version. If a user knows about that, they can find the old version, and run it using the full path, or, they can change the PATH order to make the old version come first in the PATH (which *may* cause some ported programs to fail). They can also learn to use the *NIX version. It is a very sloppy implementation, that can cause many problems, but it is what we have to work with.

Quote
If you ask me, I'd rather be stupid for letting some tool(!) install the DLLs and porting apps than wasting my time juggling the DLL installs.

It isn't really a case of being "stupid". It is a case of using the proper tools to do the job. You can use a rock to hammer nails, but it is smarter to use a hammer. Unfortunately, the hammer chosen is not exactly the best, but it is better than a rock.

Joop

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 56
  • Posts: 543
    • View Profile
Re: Arca Noae Package Manager Comments
« Reply #16 on: January 20, 2016, 08:00:16 pm »
After I installed the Package Manager and downloaded the needed packages, finally, I could use OO.
BTW, yum/rpm installs a lot more than just some DLLs.
And you do know in detail what yum/rpm did? No, see my first comment about it. And what if something breaks, you know how to solve?
Up to now I did install all myself. Yes, had have troubles in starting up, but always it did go back to or nothing mentioned in the read.me, install or whatever they call the file or I did read it wrong because my native is not English. I just want to know what's happening on my machine and what's installed on it.

Doug Bissett

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 53
  • Posts: 1313
    • View Profile
Re: Arca Noae Package Manager Comments
« Reply #17 on: January 21, 2016, 09:03:09 am »
Quote
I just want to know what's happening on my machine and what's installed on it.

With Arca Noae Package Manager, you do have the option to ask what was, or will be, installed by selecting a package (they are all listed for you), RMB and select Information and/or Contents from the menu. You can do that from YUM too, if you can remember the commands to do it. The information may be incorrect, if the package maintainer did it wrong, but that is true of most things.

There is also a YUM command (or perhaps it is an RPM command, I don't remember) that will list all of the packages that you have installed, but ANPM does that automatically, and it lists all of the available packages that you do not have installed.

So far (for me), if there is something wrong with a package, ANPM has simply suggested reporting the problem, and it declines to install whatever is broken. Once the problem is fixed, it will do the install. Not 100% ideal, but so much better than just using YUM, and YUM (even with all of it's faults) is so much better than trying to sort it out for yourself. Of course, there could be cases where the user needs to do something manually to recover from RPM/YUM faults, but somebody at Arca Noae will probably tell the world what needs to be done, after the problem is fixed.

Jochen Schäfer

  • Full Member
  • ***
  • Thank You
  • -Given: 18
  • -Receive: 7
  • Posts: 118
    • View Profile
Re: Arca Noae Package Manager Comments
« Reply #18 on: January 21, 2016, 10:46:37 am »
After I installed the Package Manager and downloaded the needed packages, finally, I could use OO.
BTW, yum/rpm installs a lot more than just some DLLs.
And you do know in detail what yum/rpm did? No, see my first comment about it. And what if something breaks, you know how to solve?
The same way, one would use, if one manages dependencies manually: Searching.

Andi B.

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 22
  • Posts: 487
    • View Profile
Re: Arca Noae Package Manager Comments
« Reply #19 on: January 21, 2016, 01:29:52 pm »
Quote
Unfortunately, those who do the porting have decided that this is the way that they will distribute their work. Like it or not, we, the users, are given little choice but to follow, do a LOT of manual work, or quit using ported programs.
One reason why they have chosen to do it the YUM/RPM way was because the other way did not work in so much cases. And it was no longer possible to support all these different partly broken installations. Simply cause the programs we now want to use are so much more complex to install then they were ten years ago and the casual user is to lazy or to dumb to follow the manual installation guides and he does not remember where he spread all these different versions of dlls all over his system.

Quote
And you do know in detail what yum/rpm did?
I consider myself a very experienced user and programmer. But even I do not no know f.e. all the details OS/2 works. But that is no reason for not using it. I'm pretty sure you and every other people on this planet are using so much devices/programs/machines these days without having much clue what they are doing in detail. But for me that's no reason to not benefit from them. Of course you can choose different and do not benefit from them. You can also choose to program you own Internet browser, your own office package, your own printing subsystem, your own development environment, your own pdf viewer, your own sync tool, your own installation tool ....

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Thank You
  • -Given: 471
  • -Receive: 95
  • Posts: 2664
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: Arca Noae Package Manager Comments
« Reply #20 on: January 21, 2016, 02:04:05 pm »
Hi

I don't think that there is secrecy on what RPM/YUM does. If someone reads how the FHS is organized and how to make an RPM package that is the end of the mystery. The issue is only a thing of personal taste (like mine is that I dislike FHS and to be stored on the root drive). But Sometimes even with WarpIn you are not sure what files are the installer putting on your HDD. You may extract the WPI file, look inside of it to see the files and the script of what does it has, I guess the same things applies with the RPM packages.

The feature of installing software from a server is not the future, it is the present. Every other platform is doing it and not copying it with the reason "just to be original" does not make sense to me. What may be dangerous is what Apple IOS is doing, that you can "ONLY" install software from the Store and not download it and installing it as regular software....which is not happening here.

Regards
Martin Iturbide
OS2World NewsMaster
... just share the dream.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 169
  • Posts: 2434
    • View Profile
Re: Arca Noae Package Manager Comments
« Reply #21 on: January 21, 2016, 06:11:06 pm »

The feature of installing software from a server is not the future, it is the present. Every other platform is doing it and not copying it with the reason "just to be original" does not make sense to me. What may be dangerous is what Apple IOS is doing, that you can "ONLY" install software from the Store and not download it and installing it as regular software....which is not happening here.

Or worst, pushing packages on us. At least RPM/YUM is fairly open and we can use unrpm or the archive viewer to examine what a package does.
In theory RPM/YUM allows rolling back a package with ease though it can get complicated if too much depends on a package.

Doug Bissett

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 53
  • Posts: 1313
    • View Profile
Re: Arca Noae Package Manager Comments
« Reply #22 on: January 21, 2016, 08:27:50 pm »
After I installed the Package Manager and downloaded the needed packages, finally, I could use OO.
BTW, yum/rpm installs a lot more than just some DLLs.
And you do know in detail what yum/rpm did? No, see my first comment about it. And what if something breaks, you know how to solve?
The same way, one would use, if one manages dependencies manually: Searching.

Well, there are some problems there. First, you need to know what you are searching for. In a lot of cases, you will need a DLL, like STDCPP.DLL, for instance. Okay, the file is there (or not), but then you need to know what version it is. I don't know of any reliable way to determine that. Date and time mean nothing. There is rarely any bldlevel information. There *may* (or not) be a way to query it, if you know how. It probably won't work if it is too old (in fact the STCCPP.DLL installed by eCS 2.2 b2 for RPM/YUM, will prevent RPM/YUM from being able to update itself - there are instructions at Arca Noae about how to fix that problem). That leaves the user with the option of using RPM/YUM to manage the problem, or, the user needs to simply assume that they need the LATEST version of whatever a program calls for (and documentation has been known to miss requirements). Installing a down level version will probably work for a program that calls for that version, but you will probably break a program that needs the later version (and you may not discover that for a month).

Then, there are the other things that RPM/YUM supplies, that are not generally called out as being required, but I suspect that they are mostly for developers, and RPM/YUM itself.

The bottom line is, that you will end up spending half your life trying to manage that mess by yourself (and I guarantee that you will miss something, and spend a lot of time trying to figure it out, while doing it), unless you do use RPM/YUM. The Arca Noae Package Manager (free, by the way), operates YUM in a user friendly way. Unfortunately, it is still subject to failures in YUM, but it usually catches that before it causes real trouble. Just stay away from the experimental repositories. The other option is to avoid using any programs that require that stuff, but then why would you even use a computer?

RPM/YUM is NOT a good solution to the problem, but it is better than trying to manage it yourself. ANPM makes using RPM/YUM a whole lot easier, and yes, you CAN tell what it will do, before it does it, and you can tell what it did do, after it does it, if you really want to know. Just ask it (either YUM, or ANPM).

The directory structure, on the other hand, is a bit of a kludge. It does mimic what *NIX does (and it does NOT need to be on the boot drive, but it does need to be in the root of the drive that it is on), which is why it is so complicated. The only advantage to using it that way, is that it makes porting *NIX programs easier. Of course, that means that those who do the job, don't have as much work to do, so they can accomplish more with their, very valuable, time.

FWIW, I share my directory between multiple boot systems, which means that I only need to update one of them, to do all of them. So far, I have had no problems with that. It also means that if I re-install one of the boot drives, I already have all of the updates available.

Andreas Schnellbacher

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 26
  • Posts: 512
    • View Profile
Re: Arca Noae Package Manager Comments
« Reply #23 on: January 21, 2016, 10:17:18 pm »
Doug, what is your suggestion to find a way out of the misery you describe?

Doug Bissett

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 53
  • Posts: 1313
    • View Profile
Re: Arca Noae Package Manager Comments
« Reply #24 on: January 21, 2016, 11:07:42 pm »
Doug, what is your suggestion to find a way out of the misery you describe?

Now that is the main problem. The way out is for programmers to do the conversion job properly, and make the programs work like OS/2 programs are supposed to work. Unfortunately, we don't have a couple of hundred extra programmers sitting around with nothing better to do so it isn't likely to happen. That leaves us stuck with a second rate method, which does take some of the workload off of the few programmers that are available (and most of them have better things that they could be doing).

Another option is to forget about converting *NIX programs, and use what is available otherwise (which is not an option, in many cases). After that, the option is to switch to another OS. As we fall further behind the curve, option 3 is becoming the only option for a lot of people, and it is becoming more difficult to keep up to the rest of the world, so that option is becoming more common.

If somebody could win one of the big lotteries, and donate a good chunk of their winnings to the cause, it would make a difference, but probably not as much as people might think. Very few people actually know how to write software for OS/2 any more. Most of the ones that do know, are way too busy porting things to actually do it themselves.

So, here we are...   :(