some good rpm online documentation

[Calum]

http://www.redhat.com/docs/books/max-rpm/

just posting this link.
i am getting to the point where i think i will be not using rpm so much, because i am thinking of migrating from RH8 to slack 9 when i can get used to it and make it feel like home, so personally i don't need this link so much in real life.

Still, rpm is probably the most used *nix package management system, and i will certainly be reading up on it, as i only understand the most commonly used things it can do. Anyway, here's a good red hat doc about rpm.

[Ice9]

i am getting to the point where i think i will be not using rpm so much, because i am thinking of migrating from RH8 to slack 9 when i can get used to it and make it feel like home, so personally i don't need this link so much in real life.

Are you sure you wanna do that?
In order to comply with the LSB project a distro should adopt rpm as the default package management system.
At least this is what I read in the Gentoo newsletter yesterday, they are switching to rpm for that very reason ....

In my opinion LSB is a very good thing, we need more compatibility between distros, and so far my experiences with rpm have mostly been good.
It's not a perfect system but it's good enough for me as long as Void Main sticks around

[Calum]

yeah that's all well and good, but there are a lot of package management systems and rpm isn't necessarily the best one for everybody. personally i stop short of saying that all linuces should be rpm based. maybe if they standardise rpms' format then i will get more behind it, but when you can't even install a red hat rpm on a mandrake system there is something far wrong, in terms of standardisation.

also, i should point out that rpm 4.0 is installed by default with slackware 9.0 and it advises that any rpms installed must be installed using the --force --nodeps options for obvious reasons. this is the same as with LFS, and in fact i have decided to use install-log, the LFS package manager, to manage all non-slackpackage installations i install, including rpms (since the --force --nodeps really renders the rpm database laughable), and of course will be using pkgtool for slackpackages. **

what i would like to see is apt for slackpacks, that would be cool.

While rpm is a fantastic idea, and all that, and i do agree it is the best package manager for many (most) applications, i do think that until it standardises itself across distros i have doubts about accepting it as a 'standard'. slackpackages do not have this restriction since people only try and install them usually on slackware or slackware derived systems, or on LFS systems of course, but that's another story. rpm has bitten a lot more off and it will therefore take it longer to chew and ultimately swallow.

Finally, i agree with the linux standard specification people that rpm is the best choice for a standard, and what choice do they have? all other package managers are certainly less standard, but the point of truly Free and Open computing is that we get a choice. if the standard is not ideal for us, then we have other well implemented options to use instead (like some people might use apt a lot for installation and some people might use cvs, it depends on the administrator's needs and personality).

Actually red hat 8 will stay my main system until i am thoroughly at home with slack 9 and by that time i will have totally tested out both pkgtool and install-log to see whether or not i prefer rpm.

** by the way if you use an rpm based system, install-log looks like a cool way of managing any non-rpm programs you might want to install, i am thinking maybe of the source version of openoffice.org or if you decided you wanted to compile mplayer yourself. rpm is mature enough that on a red hat system you usually do not need to install these things in a non rpm way but if you do, install-log might be the thing to use to track them all. i haven't tested it yet so my comments are all totally unfounded, but there it is, worth a thought.

[Ice9]

Ok, I see your point.
The problem with rpm accross different distros, as I see and understand it (I might be completely wrong), is that they all have a different directory structure at some points.

It would be nice if all the rpm-based distros could standardize on a directory structure as well, this way developpers wouldn't have to make 3-4 different packages for the same program.
Thing is rpm is the most popular package system as far as I know so it should be the easiest system to standardize upon (not sure if I need to write that with two "p's" or not).

[Calum]

Ok, I see your point.
The problem with rpm accross different distros, as I see and understand it (I might be completely wrong), is that they all have a different directory structure at some points.

It would be nice if all the rpm-based distros could standardize on a directory structure as well, this way developpers wouldn't have to make 3-4 different packages for the same program.
Thing is rpm is the most popular package system as far as I know so it should be the easiest system to standardize upon (not sure if I need to write that with two "p's" or not).

you hit the nail right on the thumb! have a cigar!

the ultimate irony is that slackware has a totally generic directory structure! mandrake, suse, redhat, and all the biggies have got nonstandard directory structures, whereas the most standard directory structure you will find in any linux is the one in slackware, this is because they try to make their linux as similar to unix as possible. if they would all calm down and stop calling directories 'redhat' and things, and just buckle down to a proper directory structure then all this rpm hoohaw would be fixed overnight.

[Tux]

-snip-

and just buckle down to a proper directory structure then all this rpm hoohaw would be fixed overnight.

Well, The different distro also often make different patches/ommisions to their shipped kernels amongst other funny business. I understand compliling a stock kernel is pretty simple especially with resources like Void's How-to etc, but it is still hardly simple. You what alot of people are like dealing with something like spreadsheet package nevermind system administration...

But I do agree something has to be done.

[Calum]

i do not in any way advocate installshield as a model but something that is as simple to use as a windows installshield installer is what is required in linux, for standards' sake. and it will need to be totally interactive with all other package management systems so that there will be none of this dependency rubbish where the rpm version of something thinks you haven't got glibc installed because you installed it from a .deb file and so on.

[Void Main]

Oh you guys are a bunch of whiners. :) The issues you are complaining about are deeper than the installer level. And which "standard UNIX" directory structure are you referring to? BSD style or SysV style because they are both would be considered "standard UNIX" if there is such a thing, and then mostly relating to the init process. For example, you would consider Solaris UNIX right? It uses SysV style init and is much closer to a Red Hat directory structure than a Slackware. Slackware is more BSD like. But that really has nothing to do with what software will or will not run on the distribution.

Now whether an application will run depends on whether or not it was compiled and dynamically linked to specific libraries. If the application was statically linked chances are it will run on any Linux system but most applications are dynamically linked. There are advantages and disadvantages to both types of linking. If dynamically linked you most certainly need the libraries available that were used when the program was compiled in the first place, if you don't the program will not run.

AIX, HP-UX, Solaris, BSD, etc, are all UNIX yet you can't run software compiled for one on any of the others. In addition to just OS incompatibilities you usually have processor and endian differences (hardware). For instance, I can't run Solaris x86 applications on Solaris SPARC, let alone run Solaris x86 apps on BSD. Likewise I can't run RedHat PPC binaries on RedHat x86. So there are more issues than even just dynamic libraries or installer differences. Now, there have been attempts to make the binary formats more cross-platform (ELF, Java, etc) but I have found that there is usually a penalty involved with these cross-platform binaries. Performance being a big one, unreasonable limitations being another.

RPM is one of many package managers that are designed to keep track of what software you have installed and when installing a new application check the requirements and make sure you have met those requirements (usually for shared libraries).

You are absolutely correct that RPM is a waste of time if all you are going to do is "rpm --nodeps --force". That makes no sense and I would use a source tarball before I would ever use RPM in that manner. I don't use *.debs in Red Hat, nor do I desire to and I don't use RPMs in Debian, nor do I desire to. Most/all applications I need are in the format I need them. If they don't exist I either use the source or I create my own RPM and install it. RPM is a great thing, if you understand it and use it properly.

I personally don't want all the Linux system to be the same. I like the way Red Hat does things so I use Red Hat, I don't want Red Hat to be set up like Slackware. Now people who like Slackware would not like Slackware to be set up like Red Hat. While that diversity exists it's unlikely you will see a "one size fits all". If that's what you want, use Windows. That's not what I want. :) But that's bad advice, don't think Windows is any better. I have a stack of CDs about 4 feet tall downstairs that I purchased for my Microsoft operating system that will not run on today's Microsoft operating systems. I would rather use free/Free software if I have to upgrade my software every time I upgrade my operating system.

I have come to the realization that it is an imperfect world and am content with it. I'm not saying we shouldn't strive to make it a perfect world. It's much closer now that RedHat 9 is here. :)

[Tux]

I am perfectly happy with things beign different, thats why i'm a Linux user. But for linux to hit the big time, I think there need to be a little bit more inter-operablility between the major distro's. I think that kind of thing would make it a little easier for newbies coming into the Linux world.
It's not like I think there's a major problem, most RPM based distributions are good enough. If apt for rpm is used with a good repository - who even needs extensive compatibility between the way different distro's do things.

[Void Main]

apt is an excellent thing. I believe that is what you all really want. That is, you want apt repositories for each distro and each version of each distro, each containing the same software packages compiled and targeted for your operating system. I agree that would be a good thing and I see that day coming. Then no matter what operating system you are on you could type "apt-get install mplayer" and get the same thing. The package would come from a different place and maybe it would install different prereqs but at the highest level you type "gmplayer" and get the same thing on every OS. I see that day coming but I don't know how far away it is.

Debian pretty much has this covered across all the Debian versions and processor families. It's spreading to Red Hat but I believe for it to really take off there should be "official" Red Hat repositories supported by Red Hat. And then have unofficial repositories for the non-supported architectures. I don't know if it will happen but I believe it would be a good thing and a natural evolution.

Then of course apt would have to be ported to all the other distros and similar repositories would have to be set up. For instance, the underlying package format for Debian is "deb" packages and are the format of the packages contained in the Debian repositories. Red Hat uses RPM so that is the format that is stored in the Red Hat repositories and apt has been modified to handle it. In Slackware you would have to modify apt to work with tgz packages and have a repository set up for each Slackware version. And so on... Then we would have a perfect world. :)

[Tux]

Where there's a will, there's a way....

[Tux]

And where there's an Opensource development team it could happen quite quickly..

[Void Main]

Then if we could get all distros to buy into using apt I believe to make it work and ultimately have repositories that roughly match as far as available applications we need to have an overall higher level repository of source code. Any programmer that wants to have his code in the distro repositories would enter it in the source repository and it would have to be a responsibility of someone to ensure that this application gets compiled and put into the respective distro package format and entered into each repository. I don't know who that responsibility should fall on (author, vendor, etc) but I think it is necessary. Before you know it, cats and dogs will be living together.

[Calum]

i agree totally with all the stuff you said in your last 3 posts void main, you raise some very good points.

when i said directory structure, all i meant was that instead of having directories called /usr/share/mdk and /usr/lib/redhat (yes i just made them up, but there are some like that hanging around in most distros), which ruins any binary rpms trying to install into those directories on another system (installing an RH rpm in mandrake and the libraries it wants are not in /usr/lib/redhat or something, you get the idea), we could have the normal basic sensible directory structure that everybody knows and can probably draw a diagram of on a napkin if called to do so.

also, when installing a package that depends on 'bzip2' and i cannot install 'bzip2' because i already have 'bz2-mdk' installed, and i cannot uninstall bz2-mdk because that'll break another 38 programs (which will in turn break.... ) i would be grateful for a situation where a binary rpm can be installed on any rpm based system. this is as you say, architecture dependent and also system dependent, but if we be reasonable i believe we can hammer down a requirement for all linux 386 style rpms to be compatible with all participating systems, and for all 586 and 686 rpms to be compatible with any participating system that runs on a 586 or a 686 (and i know very little about it but i would like to see x86 clones like amd and cyrix chips be fully supported by this format even at a cost to performance (which i am not convinced would be a big one)), now source rpms and maybe machine/system specific binary rpms could still be available, but so long as everybody made a big deal of the fact that there was a standard and that people should keep to it for their own good, the more easy it would be for people to just click and run when they are installing new rpms on their systems (especially important when we are now going to see a continuous stream of newbies as linux swells in popularity). At the moment a lot of binary only rpms are only out for red hat or only out for SuSE and those rpms don't work on other systems or even some versions of the system they are supposed to be for.

The issue is more or less moot when it comes to open source things, that are available as source or source rpms, but a lot of popular software (java virtual machine, flash plugin i think and others) is not available as source. also a lot of people don't know how to convert source stuff into installable binary rpms, i don't, but if i had to i could learn it, and probably will at some point. the mandrake version of rpm uses an option the red hat one doesn't have enabling the user to install a source rpm transparently as if it were a binary one, maybe that's something to think about having as a standard.

as for init scripts, why not just make all distros support both styles? contrary to popular belief, slackware supports both styles, even though it is initially set up to only use the bsd one, if something is added sysV style into a sysV init script, it will work. maybe rpm needs to have something added where rpm will read through the init scripts and figure out what style is supported? this would mean rpms would need to support both styles, i think it would be better to just say that all standard linuces fullt support both styles, myself.

just my thoughts. i do think rpm will and most likely should be the standard, but i think these issues need addressed before it can be considered a real standard.

[Void Main]

i agree totally with all the stuff you said in your last 3 posts void main, you raise some very good points.

when i said directory structure, all i meant was that instead of having directories called /usr/share/mdk and /usr/lib/redhat (yes i just made them up, but there are some like that hanging around in most distros), which ruins any binary rpms trying to install into those directories on another system (installing an RH rpm in mandrake and the libraries it wants are not in /usr/lib/redhat or something, you get the idea), we could have the normal basic sensible directory structure that everybody knows and can probably draw a diagram of on a napkin if called to do so.

also, when installing a package that depends on 'bzip2' and i cannot install 'bzip2' because i already have 'bz2-mdk' installed, and i cannot uninstall bz2-mdk because that'll break another 38 programs (which will in turn break.... ) i would be grateful for a situation where a binary rpm can be installed on any rpm based system. this is as you say, architecture dependent and also system dependent, but if we be reasonable i believe we can hammer down a requirement for all linux 386 style rpms to be compatible with all participating systems, and for all 586 and 686 rpms to be compatible with any participating system that runs on a 586 or a 686 (and i know very little about it but i would like to see x86 clones like amd and cyrix chips be fully supported by this format even at a cost to performance (which i am not convinced would be a big one)), now source rpms and maybe machine/system specific binary rpms could still be available, but so long as everybody made a big deal of the fact that there was a standard and that people should keep to it for their own good, the more easy it would be for people to just click and run when they are installing new rpms on their systems (especially important when we are now going to see a continuous stream of newbies as linux swells in popularity)....

I'm not quite sure what you mean and I think you are still looking at it wrong. The real problem is that you are trying to install a Red Hat RPM on Mandrake. Just because it's an RPM doesn't mean it should install on your system. The RPM needs to be built for your distro and version. RPM, the format, is a packaging, or a box. "rpm" the command is a tool for taking what is in that box and installing it.

I'm not that familiar with Eoropean cars so I will use American cars as an example. I get my car parts in a box (RPM) for my Chevrolet (Red Hat) and my Ford (Mandrake). I use my Socket set (rpm) to install those parts. Now some car parts come in different boxes and require different tools (metric vs English units or RPM vs apt). Sure some parts will fit on either car but some are specific to each (most are specific to each). In fact most of the parts for my 1976 Camaro will not fit on my 1996 Camaro. And some people who do not understand "rpm" might think it closer to a hammer than a socket set. Sure, the car manufacturers could get together so every part on the Chevy will fit on the Ford but then they would be the exact same car and what would the point be of having both?

I know a lot of people just like you who are severely frustrated because of things like this. But to me it's like a person walking into a car parts store and saying "I need a new muffler". The store clerk would ask you what the make/model/year of your car is. You wouldn't say "what's the difference, just give me a muffler, it should fit on all cars". Or maybe you would. :) And would you expect the car parts store to have a muffler for every make/model/year of car ever made? Again, maybe you would. :) But that *is* the issue. We do want to be able to get any part in any box we want. It is achievable but it will take a lot of work and coordination and the Linux world would be better for it. Or we could all just switch to Debian and be done with it. :)

...At the moment a lot of binary only rpms are only out for red hat or only out for SuSE and those rpms don't work on other systems or even some versions of the system they are supposed to be for.

If that is your hangup then I suggest picking one of those other distros that have most of the software you want. But who's fault is it that not all applications are available in every distros packaging format? Right now, the answer is the author and the user. The distro vendor picks a number of applications that they want to include and support. They just can't include everything and in fact can only include a tiny fraction of the software available to support. They only have so many resources and applications are in a wide varying degree of completeness, stability, compatibility, usefulness, etc, etc because they are written by whoever wants to write one.

As it stands right now popular applications that are not included by a distribution will get some volunteer somewhere to put that application into that particular distributions packaging format and made available for download (someone has to also donate the space and bandwidth to host those applications). Sure if everyone used a single distro this would become easier but who wants a single distro? Distro's want to be unique, even if it means that at some deep level they are not compatible.

The issue is more or less moot when it comes to open source things, that are available as source or source rpms, but a lot of popular software (java virtual machine, flash plugin i think and others) is not available as source. also a lot of people don't know how to convert source stuff into installable binary rpms, i don't, but if i had to i could learn it, and probably will at some point. the mandrake version of rpm uses an option the red hat one doesn't have enabling the user to install a source rpm transparently as if it were a binary one, maybe that's something to think about having as a standard.

The command to create binary RPMs from SRC RPMs is "rpm --rebuild xxx.src.rpm" or if you have the newest version of RPM it is "rpmbuild --rebuild xxx.src.rpm", see man rpmbuild and man rpm

as for init scripts, why not just make all distros support both styles? contrary to popular belief, slackware supports both styles, even though it is initially set up to only use the bsd one, if something is added sysV style into a sysV init script, it will work. maybe rpm needs to have something added where rpm will read through the init scripts and figure out what style is supported? this would mean rpms would need to support both styles, i think it would be better to just say that all standard linuces fullt support both styles, myself.

Contrary to popular belief all distros support both styles. Luke, you have the source. I could convert my Red Hat system to BSD style in very little time. The init processes are not large things and if you know both you could use either. Of course Red Hat only includes graphical tools for the SysV style but who uses graphical tools? People that use graphical tools could care less which init style is used anyway. I don't like the BSD style init and it's one of the many reasons I chose Red Hat as my OS of choice. It has very nice init management and is layed out just about the way I like it. And I *do* like the command line tools "chkconfig" and "service".

just my thoughts. i do think rpm will and most likely should be the standard, but i think these issues need addressed before it can be considered a real standard.

Again, I think the issues that you refer to are not RPM issues but software repository issues. As far as whether RPM should be the standard I don't know whether I agree with that. I'm sure the Debian users would have a *huge* beef with that. Again, some people like working on autos that have their units in metric and use metrics tools because it makes sense to them and some prefer the English units. No one could argue that metric is easier unless you've been using English all your life. :)