• 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

RPM packager

Started by minou, 2011.08.28, 07:35:09

Previous topic - Next topic

Do you want an RPM/YUM implementation for OS/2 that uses the Unix/Linux "Filesystem Hierarchy Standard" (/home, /var, /usr, /etc..)?

Yes
14 (41.2%)
No
18 (52.9%)
I don't know
2 (5.9%)

Total Members Voted: 0

dmik

I must explicitly state that we are *not* trying to make Linux out of OS/2. We want to keep the native "weightlessness" of OS/2, the ability to work for months w/o maintenance, the possibility to unzip the boot drive onto a new hard disk and get it running, as well as the WPS concepts; all just powered up with new technologies and software.

Pete

Hi

To os2world.com guys:-

I've now given up on trying to follow this and other discussions on this forum due to the difficulty of getting pages to display.

As this has been an ongoing problem for a long time now and the problem is getting worse I can only suggest that you look at reworking the website using software that actually works.

I do not expect to be able to access any response from yourselves so will "look in" from time to time to see if the problem(s) have been resolved.

Regards

Pete

Blonde Guy

I tried to vote yes in the poll, but I got an error message.

I make the Suntan Special product to do maintenance on OS/2 and eCS systems. To do that, I've had to interface with all of the installers for OS/2 and eCS. I'm looking forward to adding support for RPM and YUM when I get the time. One thing that would help a lot for acceptance is to make a kind of UNIXROOT that would let people put the standard file system in a custom location. Forgive me if that is already the case.

I value having Linux ports and I believe the developers who say it's a good thing. I also value my legacy setups, all of which are supported by Suntan Special. I will have no trouble at all merging the two concepts, unless there is something in RPM/YUM that really forbids coexistence.
Expert Consulting for OS/2 and eComStation

Fahrvenugen

#93
Dmik,

I do want to thank you for trying to explain the reasoning for YUM / RPM / FHS.  However a few things have still left me with questions in my mind that just don't make sense of what you're talking about.  To begin:

Quote from: dmik on 2011.09.01, 22:10:04
Quote
Windows does not use FHS.

I don't use Windows. Windows is unmanageable. Mostly because it has nothing like RPM. However, I'm being frequently asked by some friends to reinstall their copy of Windows every several months because it is screwed, or because there is a virus, or because it is screwed and there is a virus. If they succeed in convincing me to help them I install them Ubuntu (or suggest to buy a Mac). Even my blonde girlfriend has Ubuntu installed and feels pretty much happy with it (it's been working for years on her notebook w/o any maintenance, just like OS/2 actually). So Windows is a bad example.

I understand your dislike of Windows, but reading the above seems to suggest to me that you're trying to say Windows gets messed up due to a lack of FHS and / or RPM, or gets viruses due to a lack of RPM, or both.  

Of course there are viruses, malware, spyware, etc - which can infect Windows.  However I doubt it has a whole lot of anything to do with a lack of FHS or RPM.

But setting that aside dmik, one thing I'm confused abut is the mixed message we're getting.  In one message you say:


Quote
I can only repeat again that RPM has noting to do with FHS. Without FHS we will have to a) invent our own FHS and b) maintain a huge amount of OS/2-specific patches in every program ported from Linux which will be the constant source of bugs. Neither of these things will make programs better serve the user's needs. They will only be sucking our resources resulting in less software and bigger release delays. This makes no sense. Please stop aching and better learn to think different.

Okay, so part of this is to make things easier to port apps from Linux.  No difficulty there, I can understand that.  I have used ported apps on OS/2 quite a bit and I can see the value in using ported apps.  And RPM doesn't need to be linked to FHS or the file system layout.

But then in another message you say:

Quote
Yes, RPM will dictate you the FS layout for all system components it manages (and for applications by default, unless the application developer makes the application relocatable and enables this function when packaging it with RPM). The dictatorship in the area of some system components is what you already have though.

So according to the above quote, yes - RPM does have something to do with the file system layout - it'll dictate the layout for what it manages.

If I understand, RPM has "nothing to do with FHS", but "RPM will dictate you the FS layout for all system components it manages"

Can you please explain what seems to be 2 opposite statements?  Thanks.

Ivan,

Quote from: ivan
That may sound hard but I have a business to keep running and making money.  Anything that messes with the computers has the potential to stop the business and is so discarded out of hand - we aren't playing with computers, they are essential to the business.

I have to agree with you here.  For those of us who do use OS/2 as part of our jobs, where our livelihood (or a business or organization) depends on OS/2 and our knowledge of how it works, how it is set up, and how to fix it if it does happen to break (fortunately this is rare with OS/2), introducing a significant change in the file system structure - regardless of the technical reasons for that introduction (even if the reasons are sound and make sense to developers) - presents a significant risk.  I'm not saying that FHS / RPM / YUM is a bad thing.  I just share your view for caution - especially on any production system.




Pete

Hi dmik

Quote from: dmik on 2011.09.01, 03:42:28

Pete, something went wrong during the installation. Either you made a mistake at some installation step (maybe you forgot to reboot?) or you have an environment that the RPM installer does not expect. If you do it right, "yum" is in PATH after reboot and you don't need to look for it in \usr\bin. Please check it once again. If the problem persists, I suggest you to open a ticket at http://svn.netlabs.org/rpm and provide more details about what you did (exactly) and your environment; this thread is not an appropriate place for that.


Found the problem: an existing "python path" in config.sys.

Having REM'd that and rebooted yum works - of course, the software relying on the now REM'd python path does not...

Regards

Pete


aschn

Quote from: dmik on 2011.09.02, 15:16:09
I must explicitly state that we are *not* trying to make Linux out of
OS/2.
Dmik, please go ahead. You really know what you're talking about.

--
Andreas Schnellbacher

dmik

#96
Blonde Guy, yes, the UNIXROOT tree may live in any directory on any hard disk. It is recommended to install it to the root ATM (there may be a few exceptional applications still having something hard-coded like /bin/usr instead of /@unixroot/bin/usr that will fail if UNIXROOT is not at root -- this needs testing) but this is all fixable (we have plans to fix them all at once at LIBC level). Other than that, YUM has a Python interface which you may use to control it. RPM itself has a C interface.

Fahrvenugen, yes, sure, I love questions (and sometimes my explanations may be not clear enough indeed).

Regarding Windows, yes, I do really think that the Windows mess is a consequence of the lack of a tool like RPM. As a result, each vendor uses its own approach, installs files in a way he thinks is the best, leaves garbage all over (including system directories!), stores hundreds of MB of stuff you don't need (like the installer files) in well hidden places. All this means that if you ever installed an application, you won't be able to completely remove it later, even if you don't need it; the uninstallation procedure is never revertible on Windows. Subsequently, if you install software from time to time, your system directories will finally get so big that you will have to kill the whole installation. Everybody knows how painful it is to reinstall Windows: you need to find/download/reinstall every piece of software + a big bunch of drivers. This may take many days.

RPM (or DPKG) solves *all* of these problems. You know the origin of each file in the system, the application it belongs to, and the version of this application. If you uninstall the application, *all* its files are removed (except the application data in your user directory which includes application settings and documents you created), so you may install/uninstall as often as you like without any impact. The only thing you need to do after performing a fresh installation of the OS to get all your applications back, is |yum install <your_beloved_app1> <your_beloved_app_2> <etc...>|. A single command.

The statements you mention are not actually opposite. When I say "RPM forces the FS layout" I mean that most system packages will install files to the locations predefined by the software vendors. While RPM itself has a mechanism that allows creation of packages whose installation paths may be changed (prefixed) at the installation time, the whole model is not designed to be used that way: it is designed to not require any user interaction when installing software (which implies predefined paths). In this sense, FHS is just a logical complement to this model because it documents the standard on common system locations (so that vendors don't have to invent their own predefined paths for each new software package). Besides that, FHS happened to be used by many Unix environments (and, consequently, by many Unix programs), for similar purposes.

Pete, glad to hear that. Must be a conflicting version of some python library (wouldn't be the case if the other installation was also RPM-managed -)

aschn, thanks Andreas.

Pete

Hi

Having got yum working I can see that it needs a bit of work.

Using yum to list available applications for installation results in a load of text scrolling past onscreen - not much chance of selecting an app if you cannot read the screen fast enough  :-)

I resolved that issue by directing output to a file. Having read the file I do not see anything that I currently want to install...

Out of Interest: is there a yum uninstall yum command or is that something that needs to be done manually?

Regards

Pete


David McKenna

Pete said:

"Using yum to list available applications for installation results in a load of text scrolling past onscreen - not much chance of selecting an app if you cannot read the screen fast enough  :-)"

  Yes... this is the number one reason why YUM really needs a GUI to be comfortable to use on eCS IMO....

Regards,

Dave McKenna

ivan

Dmik, you say
Quoteglad to hear that. Must be a conflicting version of some python library (wouldn't be the case if the other installation was also RPM-managed
Do you mean that somehow RPM is going to magically change other programs so they won't need specific versions of libraries, because I don't believe it.

I have a python path listed in config.sys and it appears, at the moment, all programs that need anything from there are quite happy with it.

I and, I expect, many other practical users of OS/2 or eCS don't want, or need, the re-invention of the wheel.  The only time I would consider changing the file system structure is if someone ported LibreOffice and it absolutely had to have a specific directory structure.

So far, apart from Java6, QT4 and those applications based on it, Paul and Ko Myung-Hun have been the people that have ported practical programs - Scribus, rsync, gcc v4.x.x and many utilities, vlc, k movie player etc, none of which mess with our boot drive image or standard directory structure.  If RPM is so good why can't it do the same?

As I have said before, our servers and workstations are our livelihood, any messing with that will not be tolerated.  Neither will anything that requires going round to each workstation just to do an update of a program - at the moment I can let the upgrade server do that overnight without any intervention on my part.   

CDRWSel

Many ported programs need UNIXROOT under config.sys which is unique.
Unixroot should be program dependant and not the same coded under config.sys

Why RPM/YUM is bad ! It uses a lot of place on the disk and when you use SSD, this reduces SSD lifetime as I could see it (I have 2 SSD and checked internal counters). SSD needs lot of free space to correctly optimize nand utilization. Less nand are free, less is its lifetime.

I could see SSD out of order after just one and a half year !
SSD has a very high price compared to HD drive and it isn't acceptable to have tool for maintenance purpose only contributing into lifetime decrease for the reason above. 

If RPM/YUM could less than 10 MB as full size with unixroot removed restriction, it could become an alternative for Unix/linux programs.     

dmik

Pete, having got the yum/rpm bootstrap working needs no more work than having got any other application distributed as ZIP or WPI working. So not quite clear why you explicitly mention that.

Your argument about the long output of yum is childish. Any command line application has the same problem, yum is nothing special here. But you normally don't need to list all available packages. When you want to install something, you already know its name (and you can easily limit the output to just that, see the table of commands in Wiki).

If you read the yum WPI README carefully, you will find steps necessary to uninstall it.

David McKenna, there will be a GUI soon. We significantly increased the priority of this task due to your feedback.

ivan, I said "if the other installation was *also* RPM-managed". RPM can't do anything with installations not managed by it. Regarding config.sys, see above my reply to Pete.

With RPM, you do not need to change the file structure. The RPM bootstrap (and further updates) will create the necessary structure on its own. Many programs you mentioned actually have their own UNIXROOT tree inside them which usually contains all other 3rd-party software (including system components) they need. This is bad because:

  1. It creates duplication of system components which may cause conflicts. There is no clear way to use different versions of the same DLL on OS/2, especially if they both should be loaded at the same time.
  2. Even if you manage to have two different DLL versions loaded at the same time by two different applications, some system DLLs (e.g. Qt4 or Java ones) are so big that it will have a negative impact on your system (because the shared memory area where DLLs are loaded is very limited in OS/2 and because they may use a lot of private memory for some tasks which will be duplicated) . Besides, this may also break interaction between these applications because of two copies of system data in memory.
  3. It makes it difficult for the programs to cooperate with each other (some parts of UNIXROOT are meant to be system-wide and shared across applications).
  4. Needless to say it requires putting each application to PATH/LIBPATH which requires reboots and eventually creates a mess in config.sys that you constantly need to keep an eye at (especially when you remove something from your system).

BTW, all of the above actually also applies to applications not using UNIXROOT but simply supplying everything with them and keeping it in its private directories. Yes, this is how applications are distributed on Mac but you should not compare Mac and OS/2 here. Apple has full control over the OS internals and they can optimize things to work this way; we can't. Also, a typical application on Mac doesn't have external dependencies because all frameworks Mac applications use are already supplied with the system. There is no way to achieve such a state of affairs on OS/2 (for obvious reasons).

RPM can do exactly the same of course, but since it is what we consider a bad thing, we do not want to do that. We ported RPM to solve the above problems, not to keep creating them.

All programs you mention, distributed as they are, require careful manual setup which sometimes may be hard if you are not an expert. Even if you are, you can simply mistype a single slash or a semicolon and that will break the installation. I don't know why you find this exciting.

I didn't fully understand what you were saying about the server updates. If you mean that in your infrastructure workstations run their software from the network drives so that updating the server causes all workstations to be updated, then RPM lets you do exactly the same but but in a much better way (by at least removing all the problems related to the need to run the software from a network drive).

CDRWSel, about UNIXROOT and config.sys, please see above.

Regarding the hard disk space taken by RPM. If you mean the fact that the current RPM repositories cause RPM bootstrap to install GCC binaries and LIBC headers on your machine, this is a bug and it will be fixed.

I fully understand your concerns about SSD, but it is not clear to me why you find RPM guilty here. It will only perform actions when you ask it to do so. Otherwise, it does nothing.

Regarding SSD per se, I must say that UNIXROOT is a *big* helper in this area because of its strict structure. There are basically two directories in FHS which get written to during normal operation of the OS: /var and /tmp (and /home of course); programs are not allowed to write to other directories (and under Unix/Linux they simply can't). For SSD it's just perfect: you move these two directories to a device that is fine with frequent writes (e.g. to RAM-disk) and live happily.

Pete

Hi dmik

I mentioned that I got it working because when 1st installed it did not work due to the python path that already existed in my config.sys file. I would have expected yum/rpm to look for python within the UNIXROOT\bin or UNIXROOT\user\bin directories.

Your point about installing something is rather lame. I do *not* know what packages are available therefore I do *not* know any package names and could not simply issue a command to install a package.

As for uninstalling: Yes, it is gone.

Regards

Pete



CDRWSel

I need most space as possible on the SSD for SSD safety and if you look the required space by RPM/YUM, very big.

I need each programs (full) in its own path and not parts of program under a same path (unixroot). I need to preserve what was the interesting part of OS/2 - eCS which was the possibility to move the program path under an other path with a single drag/drop.

RPM/YUM is not able to do this and uses process like older windows resulting into overwrite of dll or changed dll no more usable by some programs etc...

Windows is now going out of this process due to lot of problems and if you see how many  people are interested by portableapps, it should tell you that you are going wrong !

Today, the best installer is warpin (very easy and realy end user oriented while RPM/YUM is developper and server oriented)
No need to unzip programs and do manual updates because all these steps are done by warpin.

dmik

Pete, thank you, we will add a line to README that all previous installations of python need to be removed.

I think you misunderstood me again. If you want to install Java, you type |yum search java| and it will show you the exact names of the packages whose descriptions or summaries contain the word "java". If you don't know the name of the program you want to install but still want to install it, well, this is unusual, as I said.

CDRWSel, what is your definition of "very big"?

It was never possible to move the program to a different location with drag & drop on OS/2 (except very trivial programs that don't have entries in config.sys and don't have WPS objects).

What you say about RPM/YUM further shows that you have neither knowledge nor even basic understanding of what RPM/YUM is (and you don't seem to know WarpIn well too). I'm not going to repeat everything once again, sorry. Please read the respective sources of information on the Internet and ask questions if you have them. Your words about portable applications show that you have weak understanding on how they work and also that you don't read what I write to other people. Please do.