OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: Martin Iturbide on April 27, 2015, 01:09:49 am

Title: RPM/YUM - Moving unixroot tree away from the root directory
Post by: Martin Iturbide on April 27, 2015, 01:09:49 am
Hi.

Even that I posted long time ago my dislike for RPM/YUM I'm using it now because it is more simple to find the dependencies of a package when you use it.

My dislike is for the FHS thar Linux uses - http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard (http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard). But since I can not fight that , I only ask for the next RPM/YUM to allow the user to install it on any folder and not in the root of the drive.

I had moved all the "linux styled FHS" directories/files to C:\Programs\FHS\ and all the pointers in the config.sys and it works without any problems. So I'm hoping that next versions allows the user to install RPM/YUM on the path that he desires.

Regards
Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: Silvan Scherrer on April 27, 2015, 03:59:19 pm

I had moved all the "linux styled FHS" directories/files to C:\Programs\FHS\ and all the pointers in the config.sys and it works without any problems. So I'm hoping that next versions allows the user to install RPM/YUM on the path that he desires.

This will not happen in the near future, as stated here http://trac.netlabs.org/rpm/ticket/95
Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: Martin Iturbide on April 28, 2015, 06:28:37 pm
Maybe I'm the only one with request this (Moving unixroot tree away from the root directory (http://trac.netlabs.org/rpm/ticket/95)) and that had experimented with it.
If someone also agreeds with this request, please let me know.

Regards
Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: Doug Bissett on April 28, 2015, 08:22:42 pm
Quote
If someone also agreeds with this request, please let me know.

I fail to see the point in even thinking about that. Who cares where it is, as long as it works (and it does seem to work, as long as the user cleans up the rest of the mess that is left behind when the conversion is done, and as long as YUM doesn't mess it up, which happens far too often <although it has been better recently>).   

Currently, the user has a choice to put it on the boot drive, or put it on another drive. My personal choice is to put it on another drive, and I share it between boot systems. The main advantages are that one update updates both systems, updates can be done from either system, and a new install doesn't wipe it out, it just picks up where you left off. Of course, all of that depends on the user cleaning up what gets left behind by other install methods. The main disadvantage (that I know about) happens when the host drive needs to have CHKDSK run standalone. Having a bootAble partition looks after that problem, but it can also be done using an eCS install CD.

Don't get me wrong, I am very much against the whole thing, as it exists, but it looks like we need to suck it up, and live with it, or do the work to work around it (which is proving to be very complicated).
Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: Martin Iturbide on April 29, 2015, 02:56:08 pm
Doug, it is all over again, your "negativism" disguised as a "reality check".

The thing is that "IT WORKS" you can move tree away from the root directory and "IT WORKS" !!!!
We don't need million of people testing it, we just need a small team for that.

Sometimes it is very hard to have an opinon or idea because when things are too dificult, there are complains that it is imposible. When things are easy, there are compalins that is a "potential problem" and at the end nobody whats to do anything.

Sorry guys to rant about it, but that is the way that I see it.

Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: Doug Bissett on April 29, 2015, 05:25:41 pm
Quote
Doug, it is all over again, your "negativism" disguised as a "reality check".

I am not being "negative". It is a "reality check" simply because it is totally unnecessary to move what exists (even if what exists is totally out of step with what OS/2 has always done).

Quote
The thing is that "IT WORKS" you can move tree away from the root directory and "IT WORKS" !!!!
We don't need million of people testing it, we just need a small team for that.

Perhaps it works today. If the support people don't support what you attempt, will it work tomorrow? Putting the DLLs into \os2\DLL also works, but you are on your own if you do it. Why introduce more uncertainty t6o an already delicate setup? That just does not make sense.

Quote
Sorry guys to rant about it, but that is the way that I see it.

The way I see it, is if it works as it is, leave it alone before you cause trouble, and need to spend a lot of valuable time sorting out what went wrong. Your time, and the developers time, can be better spent testing, and fixing, things that are in need of testing and fixing.

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

We just don't have the manpower to mess around with stuff that isn't important, especially when doing so may cause more problems than what we have now.
Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: Martin Iturbide on April 29, 2015, 06:57:56 pm
Doug, if it does not interest you, just move on. You can not tell the community (me neither) which will be an interesting project or not, I just suggest alternatives like everybody else does (and even documented it (http://www.os2world.com/wiki/index.php/Experiment:_Moving_the_OS/2_Directory_Structure#Moving_UNIXROOT_-_RPM.2FYUM)) . 

I don't like FHS and I don't like having millions folders on the root. I'm sucking it up using FHS (because at the end I learned about the benefits), but the least worst things is to allow the user the freedom to select where to install all the FHS structure. I'm sure that there is at least one person that shares that with me.

If you are interested in CUPS go ahead, organize the people that wants to help with CUPS on other thread. Can you inspire other people to help you with CUPS? You are welcome to do that. I don't have interest in CUPS, I don't have interest in printers or printing (right now), but I'm not telling your idea is useless and we should focus man power (which both of us don't have) on other important things.  (And I still think that there are more important things on this platform than drivers, CUPS and/or RPM/YUM)

Be happy and promote your own ideas in a positive way instead of saying that the other ideas are just useless because of the "Reality Check". Go ahead, promote your ideas on other thread.

Regards
Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: Dave Yeo on April 30, 2015, 02:04:57 am
Hi Martin, sometime ago I reviewed a bunch of code and its use of UNIXROOT and IIRC there was one program that was written in such a way that having UNIXROOT in a subdirectory could lead to failure. Since then we've gotten many more ports that use UNIXROOT and as long as the developers aren't taking installing into a subdirectory into consideration, understandable given their shortage of manpower and time, there will be a danger of failure.
One solution to cleaning up your root directory is to use TVFS. Then you can install your FHS directories anywhere you like and named however you like and symlink them to a virtual drive with a FHS setup. You can even get fancy and have multiple directories symlinked with different priorities. Being a real filesystem also means that OS/2 can handle things like symlinked DLLs.
Warpin installer, http://hobbes.nmsu.edu/download/pub/os2/system/drivers/filesys/tvfs211.exe (http://hobbes.nmsu.edu/download/pub/os2/system/drivers/filesys/tvfs211.exe), there's also a plain zip file on hobbes.
Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: Greggory Shaw on April 30, 2015, 02:32:28 am
Hi.

Even that I posted long time ago my dislike for RPM/YUM I'm using it now because it is more simple to find the dependencies of a package when you use it.

...
Regards

I hated everything in the root too Martin, but then switch to something like this layout.

Add a new partition U:  works great for keeping everything separate & easy backups ! Unless you plan on porting suff 2GBs is plenty for DLLs.

Greggory

Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: David McKenna on April 30, 2015, 04:41:26 am
  If you have Netdrive you can assign a folder to be a drive. So you could assign drive U: to C:\Programs\FHS. Then add UNIXROOT=U: to CONFIG.SYS and you are good to go.
Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: Martin Iturbide on April 30, 2015, 03:13:50 pm
Thanks for the tips. For the moment I have my experimental no-production VM machine that I use daily with the unixroot moved to C:\Programs\FHS and everything works fine, but with the usual YUM/RPM bugs that we all have from time to time (Duplicated packages, etc). And it is working fine, and all the stuff I had installed from the RPM netlabs repository (GCC, QT, Odin) is working fine.

So, I'm going to use it this way for the moment, since it is working fine.

I also see that with some of your post that there is a dislike of putting the FHS on to root of the drive too. It is too bad that bww does not consider this something to be improved on RPM/YUM. It is their development, they are free to do whatever they want with their resourced, but we are also free to have our opinion.

Regards
Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: Doug Bissett on April 30, 2015, 05:34:59 pm
Quote
It is too bad that bww does not consider this something to be improved on RPM/YUM.

BWW doesn't write the code. All they do is port it from *NIX (and many *NIX distros are abandoning YUM simply because it doesn't work very well). *NIX specifies that /usr is in the root, so that is where it ends up. *NIX also knows nothing about drive letters, so it is necessary to have all of the RPM/YUM (also *NIX ported programs) parts on the same drive as /usr. To change that means that somebody (not necessarily BWW) would need to find all of the places where things would need to change, and change them. That, in itself, would introduce a whole new area for bugs to be introduced, and it probably means that everyone who ports *NIX programs, would need to do even more work.

I think you are fighting a losing battle. If users want to use *NIX programs, it seems that we have little choice but to follow the current lead. The unfortunate part, IMO, is that there are very few *NIX programs that are really worth porting, and more effort on those few programs would likely have better results, than trying to port every program that *NIX has produced, but everybody has different needs. It is also unfortunate, that it is seen to be easier to port programs, than to write new ones from scratch. Years ago, OS/2 produced many original programs that were far superior to those on other platforms, and they got ported to other platforms. Today, the only one left is PMView. PMMail is still being developed (although very slowly) for OS/2, but VOICE is not allowed to port it to other platforms (that was part of the purchase agreement). The main "problem" with PMMail is that the main developer has not had the time to work on it, for many months, and nobody else has stepped up to help out (it is all volunteer, and any proceeds from the program go toward keeping the VOICE web site running, and to support other OS/2 projects). The battle today seems to be to keep things as simple as possible, simply because we don't have the manpower to do anything else.

I will note, that it is still my opinion, that spending a little time improving WarpIn would have been far more productive that messing around with porting RPM/YUM. Unfortunately, those who know how to do such things, decided otherwise, and now we suffer the consequences.
Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: Martin Iturbide on April 30, 2015, 08:17:20 pm
Note: I decided to slip this topic on a different thread since it changed the original subject.
Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: Martin Iturbide on April 30, 2015, 11:17:22 pm
I will note, that it is still my opinion, that spending a little time improving WarpIn would have been far more productive that messing around with porting RPM/YUM. Unfortunately, those who know how to do such things, decided otherwise, and now we suffer the consequences.

But Doug, why don't you do a funding campaign to save/improve WarpIn?

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.

So it can be nice if you get a developer and ask how much will charge to update WarpIn and after that we can try to raise the money for it.

RPM/YUM is ok with me (I learn to suck it up), the FHS sucks, installing on the root sucks, and not having a GUI sucks, but at least YUMIE is supposedly going to fix that.

Regards
Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: Mike La Martina on May 01, 2015, 12:30:48 am
I am using several QT ports of *nix programs successfully. TexMaker and TexStudio and QFTP work well for me.  Also SMPlayer and QPDFView.
Sadly my music software demands midi support which we do not have, and there are no ports of my applications anyway.
I am agnostic on the location of files.  I used to care about such things, but not anymore.
Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: Doug Bissett 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.
Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: Martin Iturbide 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
Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: ivan 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).
Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: Paul Smedley 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...
Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: Martin Iturbide 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
Title: Re: RPM/YUM - Moving unixroot tree away from the root directory
Post by: Doug Bissett 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).