Author Topic: RPM/YUM - Moving unixroot tree away from the root directory  (Read 16813 times)

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: RPM/YUM - Moving unixroot tree away from the root directory
« Reply #15 on: May 01, 2015, 05:50:45 am »
Quote
But Doug, why don't you do a funding campaign to save/improve WarpIn?

WarpIn is still maintained by Paul Ratcliffe. Anybody can add to it, although I think that Paul wants to keep control of any additions.

Quote
The value that I see on RPM/YUM:
- You can install a lot of software with a single command line command and press "Y".  WarpIn should do that too.
- You can have a server that provides the software (like some kind of store).  WarpIn are single packages, should support that.
- You can install dependencies automatically with RPM/YUM, it even downloads it.
- WarpIn misses the "Silent install" feature.

WarpIn depends on what the package creator does. It can be expanded to do more than what WarpIn does by itself (including downloading dependencies), by adding REXX code to the installer. It would be better if some of those functions could be coded directly into WarpIn, but nobody seems to want to do it (or, they don't know how). A little imagination, and some REXX, will work wonders with WarpIn, but it is somewhat limited by other things. For instance, it appears that most of the ported DLLs don't have any BLDLEVEL information included, so the only reference that a user has, is what the YUM database contains (and that may not contain the proper information, in some cases). Using file size, and date, is not adequate, but would work in most cases. Without the build information, all one can do is guess at what version is installed.

Currently, Arca Noae is working on a front end for WarpIn, and YUM. The WarpIn part is still under development, since the YUM part has taken so long to do (trying to work around problems with YUM). Once it is completed, it should be easier for a user to keep control of their system, although it can't be any better than YUM, or WarpIn.

WarpIn definitely has a "silent install" feature. It is used with the eCS installer, but I don't see any reason to want that for any other reason (well, the Arca Noae package manager will probably use it). A "store" feature could be done, but is it really worth the effort? I think that the Arca Noae package installer will have a rudimentary "store" feature, but I haven't seen what they plan, yet. I suspect that they will just collect all (or most) of the WarpIn installers into one place, and offer them in a menu. Currently, most WarpIn installers are available at HOBBES.

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4744
  • Karma: +41/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: RPM/YUM - Moving unixroot tree away from the root directory
« Reply #16 on: May 01, 2015, 06:17:28 am »
WarpIn is still maintained by Paul Ratcliffe. Anybody can add to it, although I think that Paul wants to keep control of any additions.

I disagreed with that. WarpIn is freeze and Paul Ratcliffe only fix bugs from time to time but he does not add new functionality.
Try contacting him asking for new features and let us know what he replies.

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

ivan

  • Hero Member
  • *****
  • Posts: 1559
  • Karma: +17/-0
    • View Profile
Re: RPM/YUM - Moving unixroot tree away from the root directory
« Reply #17 on: May 01, 2015, 10:21:50 am »
Hi Martin, 
Does Warpin need any new features, after all it does what it sets out to do - install a program.  It is not a system maintenance tool and was never intended as such.  RPM/YUM is not a system maintenance tool though people are trying to use it as such on eCS.

If you are looking for a system maintenance too you will first have to define what you mean (I doubt that very few OS/2-eCS systems are the same unless they are used in a commercial situation and there the IT departments are in charge of what is installed).  That leaves the home/hobby user who, generally, knows what they are doing with their systems.

What I would like to see, is a 64 bit OS/2 or, at least, better operation on multi core 64 bit processors (maybe something for the 4OS guys to think about).

Paul Smedley

  • Hero Member
  • *****
  • Posts: 2095
  • Karma: +160/-0
    • View Profile
Re: RPM/YUM - Moving unixroot tree away from the root directory
« Reply #18 on: May 01, 2015, 11:33:15 am »
One of my favorite sayings: "If it ain't broke, fix it 'till it is" seems to apply to your approach to "fixing" OS/2. All you are doing is introducing more way for something to fail. Why don't you spend time working on the CUPS project. CUPS 2.0 was broken (HP printers), last time I had time to mess with it, and CUPS is a very important program for OS/2. It is definitely far more important than moving a few directories around, for no good reason. YUM, SAMBA, RSync, QPDFView, USB drivers, ACPI, UniAud, and many more need more testing, and the developers need feedback (good or bad).

Not sure why you're suggesting Martin work on CUPS? Last I checked, he has no involvement, other than maybe testing some components...

Martin Iturbide

  • OS2World NewsMaster
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4744
  • Karma: +41/-1
  • Your Friend Wil Declares...
    • View Profile
    • Martin's Personal Blog
Re: RPM/YUM - Moving unixroot tree away from the root directory
« Reply #19 on: May 01, 2015, 02:14:38 pm »
If you are looking for a system maintenance too you will first have to define what you mean...

I just want to RPM/YUM to officially support "Moving unixroot tree away from the root directory" : )  , which is not going to happen according to bww, the conversation just went offside with all the WarpIn Stuff

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

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: RPM/YUM - Moving unixroot tree away from the root directory
« Reply #20 on: May 01, 2015, 06:54:15 pm »
Quote
I disagreed with that. WarpIn is freeze and Paul Ratcliffe only fix bugs from time to time but he does not add new functionality.
Try contacting him asking for new features and let us know what he replies.

I didn't say that WarpIn is frozen. Paul will do new features, if the person asking can tell him exactly how to do it (in which case they should probably just do it, and present Paul with the finished product). If they can't, they will take a lot of abuse from Paul. It has happened more than once to me, and I have seen him do the same to others. I do know that Alex T. is working with him to get the Arca Noae package manager to work with WarpIn, but I haven't seen any results from that, yet.

Quote
Does Warpin need any new features, after all it does what it sets out to do - install a program.  It is not a system maintenance tool and was never intended as such.  RPM/YUM is not a system maintenance tool though people are trying to use it as such on eCS.

I don't entirely agree with that. WarpIn could easily be used as a maintenance tool. In fact Chuck M. did eventually start to use it with eCSMT, before he quit doing that. ECSMT was supposed to be a system maintenance tool, but eCS became pretty static, and eCSMT seems to be abandoned. RPM/YUM is also just a package installer, but it adds a few features that could be handy, if they would work consistently. Consistency has improved a lot, since Arca Noae rattled the chain, while trying to get a package manager to work with YUM, but I still don't have a good feeling about YUM.

Quote
That leaves the home/hobby user who, generally, knows what they are doing with their systems.

Unfortunately, that is not entirely true. My guess would be that less than 10% of those users actually know what they are doing with their systems. The other 90% are the ones who are targeted by things like WarpIn, and YUM. The idea is to make it easy for those who don't know, to be able to get it right (or close enough to work).

Quote
Not sure why you're suggesting Martin work on CUPS? Last I checked, he has no involvement, other than maybe testing some components...

Well, testing, and feedback, was what I meant. Better that than wasting countless hours chasing something that doesn't need to be fixed, is likely to cause problems, and isn't important anyway.

Quote
I just want to RPM/YUM to officially support "Moving unixroot tree away from the root directory" : )  , which is not going to happen according to bww

I still need to ask WHY? There is no point in doing that, and it isn't going to improve the way that OS/2 works, even if doing it doesn't cause problems. I will agree that RPM/YUM really should put things where OS/2 has always put them, but that makes the whole project much more difficult, and those who are doing it seem to want to simplify the whole thing so they don't need to do as much work. I can't blame them for that, but surely they could have found a better way.

Quote
What I would like to see, is a 64 bit OS/2 or, at least, better operation on multi core 64 bit processors (maybe something for the 4OS guys to think about).

I haven't seen any problems with multi core processors (up to 4 cores). A 64 bit OS/2 is one of those impossible dreams. Nobody, on earth, knows enough about the kernel to be able to do it. The best that might be possible, would be to drop in a 64 bit *NIX kernel, and tweak it to work with the rest of OS/2 (which also needs major updates to work in 64 bit mode). I am sure that the OS/4 guys think about it every day, but they seem to be circling hard, just trying to figure out what the kernel actually does.

I think there is some room to improve memory allocation, IF they can figure out how that works. I also think there is room to expand on what QSINIT does with memory above the 4 GB mark, and make that available to programs, outside of the normal OS/2 memory allocation scheme. In fact, the only time I ever see my own systems use more than 2 GB of memory, is when I start up virtual machines that allocate the memory. So, a 64 bit OS/2 is really not necessary. What is necessary, is to find a way around the per process memory limits, and part of that problem is over use of shared memory (DLLs), which limits the amount of private memory available. If private memory could be allocated from the space above 4GB, that part would be solved (until shared memory eats up the rest).

Quote
RPM/YUM is not a system maintenance tool though people are trying to use it as such on eCS.

In fact neither YUM, or WarpIn (or ZIP, or RAR, or ARJ, or...), is suitable for that sort of thing (but they can be made to work). On my own systems, I have experimented with using RSync to do system maintenance. I set up one system the way I want it, then use RSync to make the rest the same (including the FHS directory structure, if you like). You do need to account for files that might be in use, when the sync takes place (an alternate boot system solves that, if you need to go that far), and you need to account for those files that should be unique to each system (the RSync filters do that). Some planning is required, but once it is working, it is pretty easy to adapt it to new machines, new programs, etc. Updates could be done over the internet, if desired, or you can load up a USB disk drive (or stick), then do the updates from that. Of course, you need some control over the systems, so that somebody doesn't change something on you (but that is probably the case anyway). There are tools to do almost anything you want. Many of them are so complicated that users have no clue how to use them (especially those tools ported from *NIX), although once you work through the useless stuff, the rest is pretty easy (in most cases).