• 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

minou

A few months ago several people show a lot of anger toward the shift to rpm packager and yum. I was quite surprised to the reaction because this very fact is the reason that I am spending the money to buy eComStation. You have to understand that the only way that OS/2 will survive is to have more developers and more applications. At the time that IBM dumped OS/2 and gave us the finger I considered myself a proud member of Team OS/2 USA. It soon became impossible to have system at a decent price that was stable. Linux quickly became my preferred system, somehow I could never accept to switch to windows at home even though this is what I have to use at work.
When I learned that eComStation was using yum and rpm I didn't hesitate to get the money necessary to paypal so wednesday I should be getting my copy of eComStation 2.1.
I have been creating packages under slackware, redhat rpm packages (as well as SuSE, Centos, Scientific Linux and Mandriva), gentoo packages and ubuntu (debian) packages for many years.
The easiest ones to create are the rpm and gentoo packages. The advantage of gentoo is that it can use packages from everybody but it is a lot more complicated than rpm. The ones who are a real pain are the debian packages. The parser barfs when you put tabs in the scripts. When I first started to create packages for ubuntu it took me hours to figure out that all the errors messages were bogus and related to the fact that the parser didn't like tabs. Using joe or vi editors were the solution as files edited with gedit would make the parser of the debian packager generate tons of error messages. rpm packages are very easy to create and very portable. Some sites have their own scripts to annoy us but once you get their macros you're ok. All that is needed to learn how to use rpm is the good old RTFM.
Watch in the next few months for ports of gcc for the PIC 32 and AVR32 as well as the debuggers for those.
I intend to get setedit to work with ARM, PIC32 and AVR32 boards on OS/2. Kate is also on my list when QT4.7 will be available for OS/2. They will be in RPM packages of course.

There is a good reason for the structure used in Linux, FreeBSD, the MAC or unix, it is so you can have a more stable system without crashes because of conflicting files. A good packager like RPM which has been proven over the years greatly help. Why recreate something that is working very well? they could have picked different ones but rpm is actually the best in the industry. urpmi or yum are popular tools that make rpm easier for those who are not familiar or do not want to familiarize themselves with rpm. If you want to give applications to install on a jump drive it is very simple as you can create a repository on any disk directory.
All the complaints I have seen on rpm were people who most likely shouldn't be allowed anywhere near a computer.
If you install rpm packages with the "--no deps" argument, do not complain for messed up data base. rpm packagers warns you that stuff is missing and if you insist it will let you screw things up with "--no deps" because sometimes you do have the files installed directly but if you do this without those files don't blame rpm for trusting your good judgement.

If you really dislike it just use unrpm and do as you please. Personnally I see the change as a brillant move that could help OS/2 get back to life. What we need now is more people willing to spend some time porting stuff. Having a similar structure as on Linux will greatly help. If you are not sure about this just check mingw. We could eventually even create binaries for OS/2 that can be created under Linux or MAC. An OS is dead without applications and there are a lot of good applications on Linux that are just waiting for people wanting to port them.

melf

The answer is quite easy for me. Such a basic and important program as an installer must behave like an eCS installer on an eCS system. I as an eCS users don't use the system because I like the *nix systems. I don't want a directory structure that is like *nix. I want to decide where my programs will install without the need to turn to some "advanced mode". I want a transparent system that I can manage and control although I'm not a programmer (or a "person that shouldn't come near a computer").

This means no objections to use ported *nix programs but a very decent demand to make programs that as very far as possible behave as I expected an eCS-program to work.

One can surely learn from other systems, but you have adapt to and to stay with the basic standard people are used to and like.
/Mikael

DougB

My view is that I don't like the way that RPM/YUM tries to take over my system. For many years, I have been able to isolate each program from the rest, and I object to having to accept somebody else's idea about how to set up my system. That is also one of the major objections that I have with Linux.

I have no problem with extracting programs from RPM packages, but all too many of them won't run unless they are installed in the very restrictive way that RPM/YUM wants to install them. FWIW, I will not bother to use a program that cannot be installed where I want to put it, in the way that I want to install it. I have never been very impressed with most Linux programs anyway. They tend to have far too many command line parameters (mostly useless), and trying to actually figure out what those parameters actually do (so I can select the 2 or 3 that actually do something useful), takes a lot of work. Most of the time, if I can't find something that works, in about 5 minutes, the program is filed in the trash, and I won't bother with it. There is no excuse for that sort of BS these days. My view is that if you want to use Linux programs, use a Linux system. ECS tends to work in a much different way, and is not subject to the restrictions that RPM/YUM wants to enforce. Not only that, but the RPM/YUM installation tends to make other programs not work (SAMBA is one of them), because it wants to change some basic system settings for it's own use. This is NOT acceptable.

We now have the QT support, which allows us to have a lot of programs, most of which have no special installation requirements (other than having the support package installed, and that is installed in a way that eCS normally works). We don't really need the Linux software, however, it does mean that we may be missing a few useful things. The main one is ClamAV. I have had little success with trying to use the later versions of that (now well out of date anyway), but if I try to install it using RPM/YUM, a lot of other things just quit working, and ClamAV is pretty restricted in what it will do. (No, I don't use ClamAVGUI, because it doesn't work the way that I want to use ClamAV).

I may install RPM/YUM on my old test machine (when I get around to rebuilding it), but it will never go back on my main machines, unless some major changes are made to the way that it works, to make it more user friendly.

If you like what RPM/YUM does, by all means use it, but don't be surprised if it causes grief with other eCS programs. I use eCS because I like the way that it works. I don't use Linux, because I don't like the way that it works. So, don't try to tell me that I need to change my ways just to use a few programs that I don't much like anyway.

Pete

Hi minou

If you are purchasing eCS2.1 because you think it uses rpm/yum then you are going to get a surprise as it does *not*; hopefully it never will.

I'm sorry but I'm 1 of those people who "who most likely shouldn't be allowed anywhere near a computer" as I do *not* like rpm/yum. Like other responses I want to install software where I want it to go *not* where someone else thinks it should go.

If I wanted a linux installer I would be using linux not eCS.

Regards

Pete

minou

yum is not understood, yum is only some wrapper for RPM. RPM is the package manager. yum just makes life easier for people not familiar with RPM. yum is not the package manager.
As for RPM, actually you can install programs anywhere you please, even without using the program manager. The problem when you do is that when you install a RPM package that needs a library that has not been installed with the RPM manager, you need to override this with --deps. I do that often on gentoo because sometimes the program will not compile with the gentoo packaging, gentoo is more restrictive with all these use flags. It makes a system more robust but hard to add stuff that is considered "unstable". On OS/2 you can do pretty much the same. I found warpin not appropriate for I like to do and RPM more robust if done correctly. My point is that it is ridiculous to go beserk because someone decided that RPM was very good and superior to warpin, a decision which I actually agree with.
When you make a mix of different packaging ways you risk having issues, yum or RPM for that matter doesn't force you to put stuff where you don't want to. All RPM does is keep track of what is installed and what is not installed. If you wanted you could have different places to install stuff, all very well supported by the spec files. You just have to do a few overrides. All that is needed is to make sure that the path is updated. Having binaries in a structured way makes it easier to maintain a system, that is why most server maintainers will always prefer some sort of UNIX platform.
This doesn't mean that you are restricted to that. The one who forces installation in certain places is not yum or RPM but whoever builds the package.
If the command line is a problem for people there is a way around that. yumex or some other program could easily be ported to OS/2.
I am not buying eComStation because of the RPM packaging use but that helped me make the decision. I have been doing embedded design and programming since the mid 70s and really disliked having to switch to windows. I had no problem with CPM, DOS and OS/2 and even windows 3.1 but with Win 95 and up and Microsoft destroying OS/2 that took the cake.
Lately the gnome group has decided to destroy our good gnome with their gnome 3.0 crap, that didn't go very well with me considering that I find KDE such a bloat that I can't stand how slow it is compare to my good old gnome 2.xx
My alternative is OS/2 or create my own fork of gnome.
I have tried going back to OS/2 4.52 but too many things just don't work as nicely as on my Linux installations (gentoo, fedora 15, SuSE 11.3, Centos and Scientific Linux). I have a lot of code on Linux which I want to port to OS/2. I do mostly embedded programming (AVR32, PIC32, ARM) and had been stuck with windows until both Atmel and Microchip came out with some support for Linux. I think that the support for AVR8 and AVR32 should be easily portable to OS/2. For the PIC32 it will probably will take a bit more work.
eComStation 2.1 with tons of bug fixed and support for RPM will make my life a lot easier. If any of you do that kind of development and have some ideas how you would prefer the directories setup for that project just let me know.
Things don't have to be installed on /usr,  /usr/local or /opt.

aschn

Quote from: DougB on 2011.08.28, 19:39:17
My view is that I don't like the way that RPM/YUM tries to take over
my system. For many years, I have been able to isolate each program
from the rest, and I object to having to accept somebody else's idea
about how to set up my system. That is also one of the major
objections that I have with Linux.

OK - apparently you talk about the File and Directory Standard (FDS).

RPM/YUM is a set of installation tools - it doesn't define a FDS. IMO,
the discussion about RPM/YUM exposures a problem the actual eCS
installation has: The outdated IBM OS/2 structure is a standard and
changing or extending it has to be well-considered and adapted
continuously to our needs.

The current additional eCS tree is a mess. No, I don't want an
additional Unix tree either - unless it's well-considered. (I already
have several of them, each larger project that deals with Unix-ported
stuff has its own.)

For me, the ClamAV example you give and what you're worrying about
doesn't have much to do with RPM/YUM. IMO, it installs a common
Unix-type file structure, because developers decided that it would
ease other and future steps.

It looks to me the first time that Dmitry and Yuri don't restrain it
on their own projects only, but on the entire eCS structure for the
future.

I really see RPM/YUM and the discussion about it as a chance to clean
up our (nearly undefined, but existing) FDS. For Unix-ported stuff, we
can't avoid an additional Unix-style FDS, but to limit that to one
additional Unix FDS would ease much for everyone.

--
Andreas Schnellbacher

Pete

Hi Andreas

I thought eCS had an FDS defined? - eCS File and Directory Standard (eFDS) http://en.ecomstation.ru/showarticle.php?id=92

I would think it is possible to make *nix  ports follow the above FDS; might make a bit of .extra work for the porter though...

Regards

Pete





Paul Smedley

Hi Pete,

Quote from: Pete on 2011.08.29, 01:51:57
I would think it is possible to make *nix  ports follow the above FDS; might make a bit of .extra work for the porter though...

Of course it is possible, but the amount of work varies from quite a bit, to a whole heap depending on the app...

CDRWSel

RPM/YUM is not good for end user. May be it could have some interest on a server.
How to have multiple unixroot defined under a same config.sys ?

>:(

cheers


lewhoo

What I fear about OS/2 port of RPM is the "easy road". Currently most of OS/2 installers allow setting destination path in an easy, GUI way. No command line switches, no configuration files editing. I fear that this will not be priority in the port and, because of lack of the programers, it will not be there for a long time. Thus because of this significant part of users may start to install in default, messy UNIX like locations and those locations will slowly become default. This is the worst scenario possible for all people preferring OS/2 over linux.

Of course, it was mentioned that there are gui tools interacting with rpms which could simplify the installation procedure and choosing target path. However, external gui tools interfering with command line tools is one of the most important reasons for me not to think of linux as a really GUI-centred, end-user oriented system. It is not that rare that the gui tool is no more fully compatible with the command line tool (or was not from the beginning). If there are to be two layers of rpm for OS/2 - command line and GUI, I would be calm only if they were developed by the same team in the same time with similar final-result priority...

DougB

QuoteHow to have multiple unixroot defined under a same config.sys ?

It can be done, to a limited extent, using a wrapper, or the facility in Dragtext. It may also be possible using RUN! (but I haven't tried that, yet). Of course, all of those are work arounds, that should not be necessary. The biggest problem is that you may need to use a different LibPath, and Begin/EndLibPath don't always work properly.

Fahrvenugen

Forgive me if I'm missing something, but I thought it had been pretty much established that the current preferred installer for eCS is Warpin.


dmik

Hello, thanks to minou for starting this discussion.

I want to make some clarifications.

What I see here (and everywhere else regarding this topic) is misunderstanding of the concepts. Despite everybody wants to think so, this problem has nothing to do with the religion. The whole question may be split up in two parts.

1. Reasons why developers want RPM.
2. Reasons why old-school users don't want RPM.

WHY DEVELOPERS WANT RPM

Ten years ago software was much simpler. A typical application would have one .EXE file and may be a couple of support .DLLs which often were pieces of external software this application depends upon. Other dependencies would include OS and Compiler runtime DLLs that were part of the OS itself and therefore were always installed on the user's computer. More over, these system dependencies were rather static as the system DLLs rarely changed in an incompatible way.

Nowadays the situation is completely different. Due to the fact that software becomes more and more specific as its complexity grows, a typical application now has a score of external dependencies which are *not* part of the OS installation. These dependencies also have their own dependencies, and each file needs to be of a particular version.

Because of the dramatically increased number of external dependencies and their stricter nature, the approach of packing each dependency with the application itself does not work any longer. Putting all hard disk space constrains aside, it creates a well-known DLL hell which, even if you manage to sort it out with hacks like LIBPATHSTRICT=T, eventually beats the whole purpose of a Dynamic Link Library which is intended to share the common parts of code among applications in order to save computer memory and other resources.

Making these external dependencies part of the OS itself (this is something eCS people have been trying to do) doesn't solve the problem because if we talk about modern software then we find that it is alive and changes over time. This means it is not static (as opposed to some ancient OS/2 system DLLs) and therefore it needs to be updated too. This just creates exactly the same problem as described above.

So the only thing the developer is left with here is to list all the dependencies in a README file, carefully describe all the steps necessary to install these dependencies and pray to god that the user has enough knowledge and experience to follow them. The more complex the software and the dependency list is, the higher is a chance that the user makes a tiny mistake that will lead to a completely broken installation, which is usually followed by blaming the developer for creating "such a crappy program" (with this statement being a completely false in 95% of all cases). Everybody is disappointed. For *no* reason.

All this created high demand in a program that would manage software installation on behalf of the end user and address the question of resolving the external dependencies in the first place as well as the task of configuring the installed software to create a proper environment that is expected by the developer for his software to work in.

RPM and YUM do just that. They are chosen simply because they turned out to be easier to port them to OS/2 than other similar tools. No religion here. No OS wars. It's like a saw for cutting wood when you realize that a knife doesn't work well any more.

WHY OLD-SCHOOL USERS DON'T WANT RPM

It's pretty clear, actually. From the days when the whole OS would fit on a 3.5' floppy disk, people used to be in charge of the entire system and its environment. They want to know what files the software puts on their hard disks, they want do decide which directory these files get written to. It all made sense back then, when the resources were very limited and the software was relatively simple so that the whole OS installation was manageable by a more or less experienced end user. Such manual control would let him optimize the system to best fit his needs and get the best out of the available hardware. It was very important.

In such situation, revoking this level of fine-grained control from hands of the end users is expectedly treated by them as the infringement on their freedom. And gives them all the mental pain it may cause.

However, today, due to the reasons described above and with the increased complexity of the software in the first place, the average end user has little to no knowledge what a particular piece of software needs and how it should be installed to work as designed. Which means, responding to the common "I want to install software where I want it to go" argument, that this argument is no longer valid. The developer of the software knows it much better.

There is no offense in this. And no limit on the freedom. You are still free to choose what software you want to install. This is where your individuality shows up. Developers offer you applications, you decide which ones serve you best and credit the respective authors. All the installation details are sorted out for you by specially designed tools. No reading installation instructions, no seeking for the right version of the dependent library, no even need to download anything by hand. And no need to care about future updates. Developers develop, users use. Everybody is happy.

I will give you another example. Consider you buy a car. If you are an average driver that needs the car to go from point A to point B, you will not complain that the engine is in front and you are not allowed to move it to the trunk. It is too complex for you to manage such things on your own and you probably have other things to do in your life that are much more important than taking care of your car's engine.

The modern software is just the same thing.

Of course, there are geeks over there that would disassemble their new cars and assemble them back putting everything the way they want. But hey, if you can do that, you will for sure be able to rip RPM off even if the whole eCS will come completely RPMized one day (it will). And especially for you we (the people who do Qt/Java/Odin/Unixports/etc.) will always provide ZIPs for all software we release as RPM. Just to make your life a bit easier. For the small but expected price -- you will have to sort out all dependencies and environment settings on your own. Which implies taking the risk of screwing up your system as well as recovering from such failures.

However, you should take into account that given the aforementioned complexity, it is impossible to describe every detail of the manual installation procedure and all possible pitfalls in the README. The multiply of the dependencies and environment parameters that the user is able to change on an eCS system gives us many hundreds of possible combinations and we are physically unable test them all. Even if we had a hundred of people in the test team (recall Windows). No need to mention that actually we have no (zero) paid testers.

All in all, our sole motivation to move to RPM is to increase the overall quality of the provided software by minimizing frequent problems that arise from incorrect installations and various conflicts with other software, as well as to simplify the task of managing software for those end users that don't want to be geeks in order to use their computers with the beloved operating system. Easy installation and update mechanisms also let us provide more frequent updates without disturbing end users too much which, again, means the increased software quality.

I hope this post helps you better understand the decision to move to RPM as well as the benefits it will give you as end users. If you have reasoned questions, feel free to ask. I will try to answer.

P.S. You may ask: we already have WarpIn. Why is it not enough? The answer: WarpIn is a great tool and it was a revolution in the OS/2 world in 90s, compared to these different application-specific installers we had (especially those ones from IBM). But WarpIn has some limitations which make it not sufficient for the modern software. These are its major limitations:

  1. No way to perform an update that removes files.
  2. Weak dependency handling, e.g. no notion of conflicts or alternatives.
  3. No support to automatically download and install dependencies.
 
An attempt to add this to WarpIn is equivalent to re-writing it from scratch. We chose RPM instead of re-involving the wheel to save the resources and direct them to other useful tasks.

P.P.S. There is a section in the RPM/2 Wiki that shows you the basics of the YUM and RPM command line, http://svn.netlabs.org/rpm/wiki/RpmHowToEndUsers. Just to demonstrate you how easy it is to install software with these tools even in the absense of the GUI front-end (which is another frequently used argument against RPM). No need to say that a GUI front-end for YUM and RPM is in our roadmap and those who attended at WSE'2011 could even see an early prototype.

P.P.P.S. The File and Directory Standard is a slightly different topic and it is not strictly connected with RPM. (Though it is connected with the question of creating an easily manageable complex system for which a tool like RPM is one of the requirements and a clearly defined FDS is another one).

miturbide

dmik, since I'm not a Linux users and I ignore how RPM works my question is:

Are the software installers made with RPM offers the same user experience for eComStation as WarpIn?
1) Can I install software with a simple double click and follow the GUI install procedure?

Thanks
Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com

miturbide

About the "eCS File and Directory Standard (eFDS)" I think it still remains too complex and should be simplify to:

- \eCs
- \Programs
- \Home

and thats all that it should be on the root.
(of course that is currently not possible because we have hardcoded /desktop /os2 /mmos2 ...etc)

I also dislike the Linux/Unix directory structure. It is too complex, thats why for example MacOS hides that structure from the user and presents a simpler one.
Martín Itúrbide
OS2World.com NewsMaster
Open Source Advocate

Skype - martiniturbide
Google Talk - martiniturbide@gmail.com