Is RPM Doomed?

Ladislav Bodnar writes "This is an opinion piece offering solutions for all the ills of the RPM Package Manager. It has been written with Slashdot in mind - it is a fairly controversial topic and I would like to hear the experiences and views of other users who have tried different package formats and different Linux distributions. The conclusions are pretty straightforward - either the big RPM-based distributions get together and develop a common standard or we will migrate to distributions offering more sophisticated and trouble-free package management. Note: the main server allows a maximum of 100 simultaneous connections. To limit the /. effect, here are two other mirrors: mirror-us and mirror-hu (the second one has larger fonts). Thanks in advance for publishing the story."

Comments

apt-get is nice

[Bloody Bastard]

I don't have problems with RPMs at all. I use apt-get since it was first introduced in Conectiva Linux, and I'm now using it in a Red Hat box. I upgraded it from 7.2 to 7.3, and the only problem I had was lack of space in /var to download the files (not my fault, but from the former sysadmin).

Re:apt-get is nice

[nehril]

someone please correct me if I'm wrong, but doesn't this article suffer from a fundamental misunderstanding? you cannot compare apt-get to rpm files. apt-get is a system for installing .debs and their dependencies. there are similar systems for rpms (apt-rpm or red carpet).

.debs suffer from all the same problems he complained about rpms having, because .debs are just a single package file. so do source code files (a la gentoo etc), since alot of your source code out there wont even ./configure without the right stuff in place. where debian has apt-get to manage the dependency nightmare, gentoo has emerge.

what he is really bellyaching about is the fact that some big rpm based distros (mandrake and redhat) don't come with free dependency management software. 99% of his anti-rpm comments are not even wrong, they are wholly irrelevant.

The last 1% that might have value is the fact that developers can't make a "universal" rpm due to all the differences in filesystem layouts among rpm based distros (note that this can a problem with .debs too). From an end user perspective even this is not a problem with a dependency manager in place. since it will find the "right stuff" for you.

Re:apt-get is nice

[coats]

...However, Abiword seems broken -- can't get the latest installed...

Can't even get it to build from source, on either Mandrake 8.2 or RedHat 7.1 developer systems... their autoconf stuff is broken in the .src.tar.gz. (This is a reported bug on their bugzilla...)

I've seen a lot of this "dependency hell" and it makes me really hate dependency on .so's: with a statically-linked build, it either works -- reliably -- or it doesn't work at all. I've heard all the .so justifications before, and from my point of view as a practicing fifty-year-old mathematician, computer scientist, and environmental modeler, it is all a lot of bunk when it comes up against the real practice of computing.

Re:apt-get is nice

[Virtex]

what he is really bellyaching about is the fact that some big rpm based distros (mandrake and redhat) don't come with free dependency management software.

I'm using Mandrake right now, and it has a free program called urpmi (User RPM Install) which works great for dependency management. It works very much like apt-get, and it's been around for years. And although I haven't seen it, doesn't Redhat's up2date handle dependencies?

Re:apt-get is nice

[jsse]

someone please correct me if I'm wrong

Sure.

Obviously the original poster didn't compare rpm to apt-get, he's talking about the convenience offered by RPM-based apt-get which solves a lot of dependencies problems in RPM.

Re:apt-get is nice

[Corvaith]

Mandrake's Software Manager is very nice. The problem isn't RPM, or the Software Manager, or any of that, as I see it.

The problem is Mandrake. Or whoever puts out these RPMs.

"Oops, sorry, we're going to start doing everything on gcc 3.1 for the next version, so... if you wanted newer packages of anything, you're out of luck."

Or replace that with any of a million other things. It's not the software format itself, it's the distrobutions that insist on putting together all these RPMs so that you can't upgrade one without upgrading your entire system.

But some of us aren't yet advanced enough to switch to Debian or Gentoo or Sorcerer, so what can we do?

Re:apt-get is nice

[coats]

Been there.

I still stand by what I said.

standardized locations, etc.

[nilstar]

I think the biggest thing we need with rpm (and other distro systems) is standardized package locations. That would help, *extremely*.... as well versioning control needs to be better. For example, I hate having to have 2-10 different versions of libraries due to programs requesting their own version, even though the newer libraries could do the job of the old ones. As well, when the rpm asks for another rpm which is not installed, but the libraries are on your machine (in the right location) it is frustrating.

I hate to say it, but maybe we need a standardized "registry" idea like in MS Windows? I hate to say it, but they do have a good idea with that.

Re:standardized locations, etc.

[TrentC]

I think the biggest thing we need with rpm (and other distro systems) is standardized package locations.

You mean something like a Filesystem Hierarchy Standard? Or maybe even a Linux Standard Base?

Jay (=
(Is there a website that rates distributions according to their adherance to these standards?)

Re:standardized locations, etc.

[smagoun]

One of the problems you bump into with standard, one-size-fits-all packages is that APIs change, and bugs get fixed/introduced. Assume package A v1.2 was compiled against package B v3.6. Now package C comes along. Package C needs package B v4.0, so it upgrades package B. In the switch from v3.7 to v4.0, however, the API changed and a misfeature was corrected. Now assume package A relies on the old API and the presence/functionality of the misfeature. Now assume package A is no longer actively developed.

This situation (and ones like it) happen all the time. That's one reason why programs often get their own copy of a library, even though it sucks from an end-user standpoint.

Nevertheless, you're right....versioning needs to be better.

Re:standardized locations, etc.

[0x0d0a]

I think the biggest thing we need with rpm (and other distro systems) is standardized package locations.

That's already done in the LSB.

The problem is that each rpm is required to contain a static list of files it installs *with pathnames*. The nice thing about this is that it lets you run rpm -qip foo.i386.rpm without executing any code (sandboxed or otherwise) to see the list of files. The stupid thing is that there then has to be a totally different rpm for every distro and every maintainer.

In addition, it means that the maintainers need to keep *two* lists of what files are in the package -- one list for "make install" and the other for rpm. This is probably the most annoying design decision of RPM I've seen. There needs to be a FILES file with a list of installed files with a gen-files script (that runs sandboxed to build FILES for not-yet-installed packages and is run at package installation time to generate FILES). Have the Makefiles read this for make install. This would make life easier for maintainers (one list of files to install), would make RPMs more reliable (no accidental adding of a file to the Makefile but not to the spec file), and would let an RPM work on any distro (if we ever get the gcc-2.7, gcc-2.96, gcc-3 stuff worked out).

even though the newer libraries could do the job of the older ones

This is true for minor version number increases, but for a major version number change, newer libraries cannot simply link to the program.

Also, the registry is a fucking stupid idea. (despite the fact that GNOME and KDE are mindlessly cloning it). The registry causes more problems than anything else I've seen on a Windows system. The MacOS did things right -- let all your centralized databases just be caches for data that can be rebuilt from files around your system. If something gets borked or corrupted...that's okay. Absolutely do *not* make your single copy of data a registry -- put the masters around the system, and let the centralized db be rebuilt if necessary.

Also, registries require "installations" and "uninstallations" instead of just copying files. You can just copy appropriate files from one system to another and run code on a Linux or MacOS box. On a Windows box, you're in for running installers to poke at the registry. And finally, I've seen tons of broken Windows installers that poke at registry entries and end up completely screwing up data that some other app uses. For example, a friend once had Sonique and WinAmp installed, but couldn't associate mp3s with either. I took a look at the registry -- Microsoft's two-entry file association scheme let the extension entry point to a nonexistent application entry, IIRC. As a result, the mp3 entry didn't show up in the Folder Options dialog in Explorer, and couldn't be reassigned, and WinAmp and Sonique kept giving errors when trying to grab associations.

The day any distro starts requiring a registry is the day I never touch that distro again. Right now, I can just uninstall GNOME if I want to do so.

Oh, and another thing. The Windows registry is a *massive* shared database. As a result, tons of stuff modifies it and causes internal fragmentation and loss of physical continuity between related keys. Then all apps use the registry heavily (God, I hate apps that poll it), so you get slow app launch times, that annoying disk churning that you hear on Windows boxes...rrrgh.

Take a look at .dll registration. On Windows, the only way the OS knows about a .systemwide dll is when you've added an entry to the registry for it. On Linux...run ldconfig, and it rebuilds the systemwide cache (ld.so.cache), which is significantly faster (contiguous, not incrementally modified, not modified by all sorts of other apps storing filename associations and the like) to read.

The registry is basically a hack, because Windows *used* to have what MS considered a worse scheme (.ini files). It isn't a very well thought out system.

Re:standardized locations, etc.

[Vlad_the_Inhaler]

Package A will have been written for and tested on the API as it was defined at the time.
The author(s) could not know what part of the API was going to become obsolete.
I work on mainframes where things are a lot more stable, but occasionally some interface is changed and something has to be done. If we are lucky (most cases), that 'something' is just recompiling. If it goes beyond that, then most times the software vendor warns us of impending problems.

Re:standardized locations, etc.

[Fluffy the Cat]

I hate having to have 2-10 different versions of libraries due to prorams requesting their own version, even though the newer libraries could do the job of the old ones

Any program linked against a library with the same major version number and the same or lower version number than the library installed should work. If the program depends on a specific minor version (as opposed to "a specific minor version or greater"), it's broken. If you have libfoo.so.1.0.1, libfoo.so.1.0.5 and libfo.so.1.0.7 you should be able to delete all of them except for the last and expect things to keep working. Applications are linked against the major version number, so they'll be using the more recent version already (run ldd on a binary and look at the first column - that's what the program is looking for, and the last column is what it's using)

Now, the problem arises when you have applications linked against different major versions. The major version is supposed to be incremented when an incompatible change in the ABI is made - that is, without recompilation, a program linked against libfoo.so.1 will not work with libfoo.so.2 (well, it might - the change may be limited to a specific part of the library that the program doesn't use. But you can't guarantee that).

So, if you have dependencies on lots of libraries with the same major version but different minor versions, your packages are broken. If you have dependencies on lots of libraries with different major numbers, then that's unavoidable and nothing to do with the packaging system.

Re:standardized locations, etc.

[GeekBoy]

>Also, the registry is a fucking stupid idea. (despite the
>fact that GNOME and KDE are mindlessly cloning it).
>The registry causes more problems than anything else
>I've seen on a Windows system. The MacOS did things
>right -- let all your centralized databases just be
> caches for data that can be rebuilt from files around
>your system.

Umm. KDE works exactly the way you describe MacOS as working. All of the KDE config file are just that, files. However, to aid performance, etc, they are built into a sort of binary "registry/database" by a program called kbuildsycoca. If it becomes fubar'd then you just rebuild it.

Re:standardized locations, etc.

[0x0d0a]

Okay, my apologies. I haven't poked around too much with KDE.

GNOME's GConf does act as a Windows-like registry.

Re:standardized locations, etc.

[SerpentMage]

While I think it is a great idea to do major and minor versions, it all stills fails because people break things.

If there is one thing I like in .NET it is the fact that you can install any system files local and have two copies on the computer. Ok hard on the hard disk space, but at least it works.

And while I hate to admit it, shared libraries do suck long term when building applications. The dependencies become nightmarish because you code against specific versions and assume certain things. I would rather simply static link it and be done with it.

Re:standardized locations, etc.

[captaineo]

On Windows, the only way the OS knows about a .systemwide dll is when you've added an entry to the registry for it.

I do agree with Windows' conventions on DLL use - '.' is always in the DLL search path, and it's conventional when starting GUI programs to chdir() to their "bin" directory... In order to get this effect on Linux, you have to stick a boilerplate script in /usr/bin that sets LD_LIBRARY_PATH, PATH, etc (Mozilla is a good example of this).

I think one avenue of attack no one has considered yet is modifying /bin/sh. Instead of using a pre-set PATH, perhaps the shell should take it upon itself to search for packages with /bin/ directories, and set LD_LIBRARY_PATH to the corresponding /lib/ directory automatically...

You have to start to think of /usr/bin not as the directory where all your executables go, but simply a directory of command names that are accessible to the shell...

Re:standardized locations, etc.

[qweqwe]

Not really. GNOME's GConf works like a database (installable schemas with defaults) with any back end you want (XML, LDAP, Postgre, raw files). It's only used for configuration (e.g. user preferences) not anything critical, so you can blow it away or damage it and your system will return to reasonable defaults. You should also be able to share them between different installations, and have a registry chain so that defaults can be maintained on a central server and users can make local changes on their servers. It also has notifications so you can be notified if a specific key changes. With notifications, there's no need to restart your application (or server) just so that the new settings can take place (no reboots either!).

Windows registries are nothing like this.

Re:standardized locations, etc.

[mattdm]

I hate to say it, but maybe we need a standardized "registry" idea like in MS Windows? I hate to say it, but they do have a good idea with that.

We have something like that. Something superior, in fact. It's called /etc.

Re:standardized locations, etc.

[rseuhs]

That's one reason why programs often get their own copy of a library, even though it sucks from an end-user standpoint.

Why does this suck from an end-user standpoint?

I personally don't care much about how many versions of some library are installed as long as the goddamned software works. I think software like everything from Loki(RIP) or Codeweavers are very well done because they don't require many libraries (Only the kernel and glibc AFAIK)

Re:standardized locations, etc.

[MSG]

In addition, it means that the maintainers need to keep *two* lists of what files are in the package -- one list for "make install" and the other for rpm. ... There needs to be a FILES file with a list of installed files with a gen-files script

Actually, you can do that. The old KDE packages did; I don't know if the new ones do. It's very easy to do if your source produces only one binary package. However, if you want to split things into more than one binary pacakge, then it is up to you to determine which files belong in which package. You can still do this automatically, but it's usually easier just to list the files in the rpm spec.

Re:standardized locations, etc.

[IamTheRealMike]

I was reading the FHS yesterday, and am still confused about one thing. It says that /usr/local and /opt are both for use by user-installed software. So where should my packages go?

Oh, and by the way, I think SuSE is basically the only fully LSB/FHS compliant distro out there, correct me if I'm wrong.

thanks -mike

Re:standardized locations, etc.

[MSG]

Maybe your package is a library, and you want to split it into "library" and "library-devel" packages, so that users don't need extra headers and devel libraries sitting around, filling up their disks.

Or, maybe you have a single source which builds a modular application, and some of those modules have dependencies that the package as a whole doesn't need. The Courier-MTA builds separate courier-ldap, courier-mysql, courier-pgsql packages so that users who want virtual hosting/aliasing using those backends can install the appropriate package, but those who don't use those features don't need openldap, mysql, and postgresql installed to run Courier.

Re:standardized locations, etc.

[joto]

I do agree with Windows' conventions on DLL use - '.' is always in the DLL search path, and it's conventional when starting GUI programs to chdir() to their "bin" directory...

Yes, this is more user-friendly. However, it is also an enormous security risk. If someone were to put a libc.so in your current directory (which quite often is not your home directory), then the system would use that instead of standard libc.

Now, you could try to patch things up the microsoft way, fixing one hole at a time, but a better solution is to simply fix the underlying architecture, and not have . in your LD_LIBRARY_PATH.

In order to get this effect on Linux, you have to stick a boilerplate script in /usr/bin that sets LD_LIBRARY_PATH, PATH, etc

And what exactly is wrong with such a boilerplate script? It is simple to write (as you mentioned, it's all boilerplate code). It is simple to understand and modify for nonstandard installations. It is reasonably efficient (at least for anything large enough to have been modularized into separate loadable libraries). And it is a lot safer than the approach you mentioned...

I think one avenue of attack no one has considered yet is modifying /bin/sh. Instead of using a pre-set PATH, perhaps the shell should take it upon itself to search for packages with /bin/ directories, and set LD_LIBRARY_PATH to the corresponding /lib/ directory automatically...

And the reason for that is because linux is intended to be a unix. Changing the semantics of /bin/sh this much would make it into something else. (And remember, we would also have to "fix" /bin/csh, /bin/zsh, /bin/ksh, and any other shell-like program people would use. You could just as well change the semantics of the exec() syscall.)

The only problem this is going to "fix" is that of removing say 3-100 lines of simple /bin/sh code from large projects like mozilla, at the cost of increased complexity, reduced flexibility, and less security in the overall system.

The alternative of some simple boilerplate shellscript for larger programs is much better.

You have to start to think of /usr/bin not as the directory where all your executables go, but simply a directory of command names that are accessible to the shell...

And surprisingly, here we seem to agree. I don't really see the purpose of putting everything in /usr/bin, and /usr/lib. Large packages/projects/subsystems/whatever should live in their own package directory (and whether it would be /usr/foo, /opt/foo, /usr/pkg/foo, or something else I don't care about, as long as package maintainers agree on it).

Shellscripts can be used to set up the execution environment (current working directory, library load path, path for executables unlikely to be of interest to end-users, etc). Symlinks can be used for everything else (manpages, etc...)

Re:standardized locations, etc.

[captaineo]

I like jcast's idea of '/etc/prefixes'. The main point is that this should be taken care of automatically by the package manager. Either that or dropping the boilerplate "export LD_LIBRARY_PATH=foo" script in /usr/bin. I consider Mozilla a good citizen in that all you have to do is link 'mozilla' into /usr/bin and you're all set to go. But consider what happens when you try to install a typical package somewhere other than /usr/local/lib - you can certainly do it with './configure --prefix=/foo', but what happens is THE ABSOLUTE PATHS TO THE LIBRARIES GET HARD-CODED INTO THE EXECUTABLES (can you tell I hate 'ld -rpath' with a vengeance?). If you decide to move the package somewhere else, all executables will break.

BTW I don't really get the whole UNIX thing about never putting '.' into PATH or LD_LIBRARY_PATH. I know it theoretically creates a vulnerability, but has anyone exploited it (in recent history)? Shouldn't binaries and libraries be installed in read-only directories, so that only root could slip in a substitute libc.so? (if root is hostile then you are fucked anyway). Sure you could theoretically be duped into running a malicous 'ls', but is this really a big enough risk to justify the torture of typing ./foo all the time? (I swear we could delay the onset of RSI by years if we eliminated './' and 'export LD_LIBRARY_PATH=...' =)

I like the idea of designating a 'core' set of libraries (libc, libpthreads, etc) and binaries (ls, cp, mv, etc) that could never be over-ridden...

I don't understand why people treat "the UNIX way" as some holy order that can't evolve into anything better. UNIX is just one system some guys at Bell Labs hacked out in the 60's. It's not without flaws. (I'm reminded of my IRIX box, which keeps the binary for 'ping' in /etc/ping...). There are lots of groups trying to "do UNIX better" (Miguel of GNOME is explicit about it); of course not all of them will succeed, but I will certainly bet you that we haven't reached the local maximum yet.

Re:standardized locations, etc.

[MSG]

I didn't say you couldn't. You only asked why you'd want to split one source into multiple binary packages.

All the same, try it sometime with a non-trivial package. It's not as simple as it seems at first, especially if you want the source packages builds without those optional packages' dependencies.

Re:standardized locations, etc.

[joto]

what happens is THE ABSOLUTE PATHS TO THE LIBRARIES GET HARD-CODED INTO THE EXECUTABLES (can you tell I hate 'ld -rpath' with a vengeance?). If you decide to move the package somewhere else, all executables will break.

I agree. This is bad.

Shouldn't binaries and libraries be installed in read-only directories, so that only root could slip in a substitute libc.so?

No, how would you add a new binary to a read-only directory then? But more seriosly, I would hate to have to be root just to load another libc.so during development.

but is this really a big enough risk to justify the torture of typing ./foo all the time?

Maybe not. You are free to add . to your path if you want to (and at the end of the path is a lot safer). This is often useful during development, and developers know how to do that. Users will mostly use binaries in /bin and /usr/bin, and there is little reason to make things more unsafe by default. Add ~/bin to your path as well, and most problems go away.

I like the idea of designating a 'core' set of libraries (libc, libpthreads, etc) and binaries (ls, cp, mv, etc) that could never be over-ridden...

Why? It makes no sense to me. It would be a big hassle for developers, and it doesn't help security much, because there will always be new "standard" shared libraries (Gnome, KDE, X11, etc...). So it wouldn't really help security except in those few cases where a "standard" shared library was involved (this is like microsoft plugging just *that* security hole, leaving everything else open). But you are free to add a this as a configuration file to ld.so. There is a possibility that someone would like it. Shells with builtin "mv", "cp", "ls", etc.. already exists (albeit for a different purpose).

I don't understand why people treat "the UNIX way" as some holy order that can't evolve into anything better. UNIX is just one system some guys at Bell Labs hacked out in the 60's.

Because otherwise things will break. We like it this way, it works, it has proven itself, and we care about source compatibility with other unices as well as international standards like posix. And we care about the flexibility unix offers to replace parts we don't like.

And while I am all for improvement, having a conservative attitude towards "fixing" means that fixes that breaks more than it fixes will rightfully not be allowed to break things. On the other hand, if the fixes are truly better in every aspect, and they can emulate old behaviour if necessary, then you are not going to see many oppose them (at least not in the linux community).

Re:standardized locations, etc.

[SerpentMage]

A: I am able to write portable code
B: I am not lazy either

So besides saying I am lazy and not able to write code please put some validation in your comments.

The reason why I say these comments regarding shared libraries is because when the number of libraries shared among applications become large conflicts will occur more than we would like to know about. And as a result you spend a huge amount of time tracking down libraries just so that your application can work.

When you say documentation can be improved, my comment is that I have time deadlines and have to make tradeoffs. And while I am not a fan of using static libraries it gives you stability.

Look at it this way. You do it right, get a conflict that is not your fault. You then have to look at what the other installation did and fix it. But of course you will look like a jackass. Or you trade off and do a static release and never have to deal with the problem?

Has anyone ever tried..

[ChronoZ]

various alternatives to RPM packaging? I don't know much about this, but I've found QNX's Package Installer to be quite efficient and trouble-free (at least in 6.1, can't say much on the new one in 6.2NC) compared to what many experience with RPMs..
Then again, RPMs would work better if more distributions were a little more uniform in their cores (UnitedLinux might solve this?)

Gentoo's Portage system r00lz

[rizzo]

Gentoo Linux uses a system called "portage" which will download, compile, and install programs from source (binary for some packages). It is fantastic. Similar to apt it will check for dependencies and get those also. But the use of source is what turns me on. I'm converting all my linux boxen to it. Even inspired me to slice up the disk on my Win2000 box and go dual-boot.

Re:Gentoo's Portage system r00lz

[0x0d0a]

And there are plenty of front ends to rpm that can also get dependencies. If rpm is too low-level for you, that's why it was designed to be *really easy* to write front ends for, what with rpmlib and --queryformat.

Re:Gentoo's Portage system r00lz

[kidlinux]

If you go to Gentoo's Website and read about the portage system, you'll see they make reference to the fact that it's similar to BSD's ports system. They mention that portage is certainly not just a ports "ripoff". I recall reading somewhere that the portage system uses the best features of ports and Debian's apt.
Although I've never used Debian, and have limited experience with ports, I wouldn't doubt it. Portage is pretty tight.

Re:Gentoo's Portage system r00lz

[Oopsz]

Umm.. Gentoo's portage system has you covered there. You can upgrade on the fly and keep your original configurations, then when you have some free time, "emerge clean world" will kill your old versions (While leaving the required files for other apps.) As well, if you're running a farm of identical servers (And if its a farm, why on earth would you have multiple configurations?), you can compile a package on one box, and install using that package on the rest of them. It's a great hybrid of Source and Binary based package management.

Re:Gentoo's Portage system r00lz

[drinkypoo]

Debconf on the other hand gives you a handy choice of user interfaces and prioritized prompt questions, and will restart your services for you when it's done.
Real professionals wouldn't do it any other way.

FUD, FUD, FUD.

1. Like openbsd's ports collection, gentoo's portage system does a so-called "fake" install and builds a package whenever you 'emerge' it. Hence, it creates a binary package which can instantly be emerged (as an install or upgrade) on other systems with the same architecture. You can always build for a common architecture, but that does defeat the entire purpose of gentoo. You can use a downloader which supports proxies, so if you choose to do upgrades by compiling, your proxy server can at least save you from downloading everything.
2. Portage doesn't have a 'handy choice of user interfaces' yet because no one's gotten around to developing one. Good thing it's so bloody easy; emerge --clean --update rsync will update your portage tree removing old entries; Keep the old entries (Which will continue to work) by not specifying --clean. emerge --update world will update all install packages which have been updated since your last world update.
3. Real professionals? What kind are those, microsoft professionals? You're not a Unix admin if you need a candy-coated GUI to administer your system. I use them sometimes too, when it's convenient, but if you depend on them, you're a cripple. Period.

You obviously know jack about portage. Please don't talk about it again until you've actually used it. Or at least read some docs on gentoo.org.

Re:Gentoo's Portage system r00lz

[Arandir]

From my own experience (undoubtedly biased by the fact that the Gentoo documentation is grossly incomplete) here is were ports beats portage:

1) Can't search portage. Under FreeBSD just do: "make search name=blarg". This will give you a wealth of information.

2) Poor documentation for portage. This may be the reason I never figured out how to do the previous. Under FreeBSD, do a "man ports" and you get all the information you need. (there's also the excellent Handbook and Porter's Guide)

3) No package descriptions! Aaaargh! If you want to know what a package does under Gentoo you download the sources and read the README in the sources. Very bad. Even a one line lazy-developer's description is better than nothing.

4) For difficult source code, it may be easier to create a Gentoo emerge file. But for simple straightforward source, the FreeBSD port Makefile is easiest.

3) Ability to install binaries packages as an option. Building from source is great, but sometimes you don't have the time.

Summary: I expect the Gentoo portage system to eventually address my concerns. In the meantime it was a very painful experience.

Re:Gentoo's Portage system r00lz

[Arandir]

emerge -s package

I just downloaded the current portage tree. I see that some ports do have descriptions, but that some do not. This is a big improvement over the last time I used it when I couldn't find any. Those empty description lines are a major pain in the ass. Go look up the description for Windowmaker. Quite useful isn't it?

Want more? Gentoo Documentation [gentoo.org]

Let me go look. I sure hope it's better than the last time (which was 1.0 or thereabouts)...

Okay, now that my eyes have stopped bleeding after those pages full of green, dark purple, light purple, red, yellow and blue highlighting, I see that there's a few more docs available. The desktop guide seems to be somewhat adequate. The portage manual is slightly easier on the eyes, and I see that it actually has a bit on "search".

Remember that Gentoo is still a "young" distribution...

First time I used Gentoo was about a year ago. It was so far from stable that LFS was easier to build. Last time I used it was version 1.0. From my perspective it seemed as if it was aimed at Gentoo developers rather than Gentoo users. It looks like 1.2 should be out soon. Maybe I'll try that.

p.s. Please note that I am not intending to rag on Gentoo. I think it had the promise at 1.0 then any other distro did at 1.0. My criticisms are aimed to improve it, not to knock it.

Re:Gentoo's Portage system r00lz

[PugMajere]

The system he was referring to is for package configuration.

I.e, I don't want to pay attention to the intricacies of how my keyboard mappings are configured. So DebConf asks me a question or 3 the first time I install the console-tools (maybe, I forget) package.

It asks the question using my choice of interfaces, i.e, a readline4 based one, a nice ncurses based one, an X based one, or a web based one. (I have no idea how the web one works, just for reference, I just know it's an option.)

From that point on, I should never be asked that question again, unless the meaning of it has changed.

The benefit here is that some simple things (like say, your workgroup that your Samba server hangs out in?) can be configured once, and your config file can be regenerated on each package upgrade. You can make changes on top of that configuration file, if you need, but many updates can be handled for you without you needing to know the details of the upgrade.

DebConf is a *really* nice tool for configuration management. In theory (it hasn't happened in practice), is that common configuration options for say, MTAs can be used, so if you want to switch from sendmail to exim you can have your old configuration information copied right over.

Mirrors

[cheezycrust]

If the other links are overloaded, you can read the story on my site. Maybe other mirrors should be posted in this thread.

I like Slackware's .tgz

[Xpilot]

No depency checking, but it also means that you don't have the problem of circular dependecies and the like. Plus you can open it with tar and gzip. Linux Packages is a great place to look for pre-built Slack packages.

I used to use RPM, but now that I've converted to Slack, I don't miss it one bit.

Re:I like Slackware's .tgz

[BrokenHalo]

I was just about to post something to the same effect. Having spent many hours trying to fix or work around broken package dependencies with RPM on RedHat and more recently Mandrake, I recently ditched both in favour of Slackware which I have found _much_ easier to maintain. Good to see I'm not alone in this...

Re:I like Slackware's .tgz

[nzkoz]

... This is a fairly odd argument. I don't like dependency checking, so I don't like RPM. Why don't you just install with rpm -Uvh --nodeps?

Luke, use the source...

[peterdaly]

I administer a few RedHat servers, mostly 6.2, and 7.2 which each perform a different function. If an RPM is offered for a piece of software I need to install, I usually download that first.

If the rpm install fails, I will spend about 3 minutes troubleshooting the issue. If I can't get it to go, I download the source and compile from scratch. 9 times out of 10 this works without having to figure out dependancies.

RPM works great when the envirnment is exactly the same as the build envirnment. When it's not...well, it just plain sucks. Source almost always works without incident.

Really, there is nothing to difficult about:
./configure
make
su
make install

Although it only works for products where the source is openly available.

RedHat needs a compile from source package format that most people can figure out. srpms may do it, but I have no clue how to use them.

-Pete

Re:Luke, use the source...

[blaze-x]

> I administer a few RedHat servers...

Once you administer 20+ of 'em with other admins, you are going to need a package management system.

Unless you think keeping notes really works :)

---
blaze-x

Re:Luke, use the source...

[garett_spencley]

I'm an administrator too but I try my hardest *never* to install from source. This is because of security and ease of maintenance.

The main concern is that if I install OpenSSH from source on all 50 of my servers when it comes time to patch it I've got myself a little inconvencience. I would most likely compile it on one machine, tar up the source directory (complete with new binaries) and do a 'make install' on all 50 machines so I don't have to recompile for each box. But this is still going to take me a lot of time.

So therefore we've set some policies in place to make keeping systems up to date and secure easy:

For starters, we've standardized on Mandrake for Linux. This helps a lot because if we have a single rpm to install it will install on all of our servers.

We also mirror the updates locally so that we don't have to worry about slow downloads and we make heavy use of urpmi to automatically grab all the updates, check dependancies, gpg signatures and install them for us.

We don't install from source unless we absolutely have to. Actually, we try not to install any software that doesn't come with Mandrake but obviously this isn't always possible. In those cases we follow the convention where everything goes in /opt/pkg_name so we can easily get rid of them if we have to.

I really like RPM for this reason. However, as you stated as long as the systems the RPM was compiled for is roughly the same it will work well. Which is why we standardized on one distro.

--
Garett

Re:Luke, use the source...

[Squeezer]

RedHat needs a compile from source package format that most people can figure out. srpms may do it, but I have no clue how to use them.

rpm --rebuild package-version.srpm
rpm -Uvh /usr/src/redhat/RPMS/i386/package-version.arc h.rpm

Or if the .tar.gz you extracted has a spec file:

rpm -bb package.spec
rpm -Uvh /usr/src/redhat/RPMS/i386/package-version.arc h.rpm

Re:Luke, use the source...

[grazzy]

True. I've been working with this exact method for years aswell.

I see nothing wrong about RPM compared to other systems, I can see why people running say Debian whine about RPM because .rpms isnt supported on THEIR system.. and I dont see as many .deb out there as there are .rpm ..

So either way if rpm is worse or better than .deb its a standard. And standards are standards because people use them - and like them. Its not .rpm that should change, maybe its .deb.

Re:Luke, use the source...

[0x0d0a]

Really, there is nothing too difficult about:
./configure
make
su
make install


Yeah. But there's the ever so much more superior checkinstall:
./configure
make
su
checkinstall

This creates and installs an RPM of all the stuff you were installing. Voila...you can uninstall, you can query rpm to find out what package a file is part of, find out if uninstalling something will break dependencies, etc, etc...all the stuff that you can't do with just make install.

Re:Luke, use the source...

[zpengo]

It's just a shame that Linux doesn't have a clean install/uninstall system like Microsoft Windows, which gets it right every time.

Err...nevermind.

Seriously, though, the magic of open source is that if something doesn't work well, people can develop an alternative to it. As Ashcroft would say, "If you don't develop innovative new technologies, then Microsoft has already won...."

Re:Luke, use the source...

[garett_spencley]

Hard choice, no matter what you do.

Well, yeah considering that there's no possible way that I could audit every single peice of code that runs on my system.

There's this myth that code is more secure than binaries. In theory this may be true but in practice we have seen tons of source distributions for packages have trojans (apache, an irc client recently had one reported on bug track, ken thompson's c compiler etc.).

I have no choice but to trust the vendor of my distro because I am simply not super man. I have audited some code (such as portmap) when I've been particularly uneasy running that particular daemon on my servers but I just can't do this for all my packages.

So I don't see how running binaries is any less secure than source packages. It's not just about convenience it's about practicality. With rpms I can have all my servers patches in minutes. Whereas with source I'm looking at a couple hours.

--
Garett

Re:Luke, use the source...

[Phroggy]

Really, there is nothing to difficult about:
./configure
make
su
make install

Yeah, ever install Mozilla that way? How about XFree86? On a PII/300? After downloading the tarball on 56k? There are advantages to binary packages.

Re:Luke, use the source...

[Hal_9000@!!!@]

RedHat needs a compile from source package format that most people can figure out. srpms may do it, but I have no clue how to use them.

rpm --rebuild name.src.rpm

That will build and install the RPM for you. If you want to customize the compiling options, do

rpm -i name.src.rpm

and manually edit /usr/src/{distro,rpm}/SPECS/name.spec to add the options you want. Then run

rpm -ba name.spec

and install the RPM in the RPMS directory.

RedHat has a HOWTO at RPM.org and I've written documentation for bluelinux.org which should be helpful.

Re:Luke, use the source...

[tannhaus]

Checkinstall works great. If there is no rpm, just download the source tar.gz and build an rpm.

You forgot to mention one thing though. You now have built an RPM...it is added into your database. If that rpm becomes a dependency for another package , it is easily found in the database.

Also, now that you have an RPM, if you have other systems, you can simply drop in the binary rpm on those systems. Sure, plain old source may work great...but have you ever tried to build a package from source on 20 different machines? Much easier to build it on one and drop the binary rpm into the others.

Re:Luke, use the source...

[nedron]

"RedHat needs a compile from source package format that most people can figure out. srpms may do it, but I have no clue how to use them."

Hmmm, man rpm worked for me the first time I tried to build from a source RPM.

Re:Luke, use the source...

[mcrbids]

You must install it first. Do a search for "checkinstall" at freshmeat.net...

Re:Luke, use the source...

[harlows_monkeys]

The main concern is that if I install OpenSSH from source on all 50 of my servers when it comes time to patch it I've got myself a little inconvencience. I would most likely compile it on one machine, tar up the source directory (complete with new binaries) and do a 'make install' on all 50 machines so I don't have to recompile for each box. But this is still going to take me a lot of time.

Have you considered making your own RPMs? It's actually pretty easy, even if you start from the original tarball. If you start from your distribution's RPM, it will be even easier.

Re:Luke, use the source...

[ninewands]

The main concern is that if I install OpenSSH from source on all 50 of my servers when it comes time to patch it I've got myself a little inconvencience.

A little work with NFS mounts will quickly give you a single-point upgrade system. I admin a mix of SGIs (5), Suns (20), Alphas (36), PCs running Solaris (12) and PCs running Linux (5 workstations and 2 Beowulfs). In our operation, we build everything that didn't come on the CDs from source, yet I only have to compile and install 5 times to update all archs and all OS's because we export the appropriate directory (/usr/local <Yeah, I know it's deprecated, but my boss has been running Unix boxen for 30 years and old habits die hard, deprecated or not.>) to all hosts.

We don't install from source unless we absolutely have to. Actually, we try not to install any software that doesn't come with Mandrake but obviously this isn't always possible. In those cases we follow the convention where everything goes in /opt/pkg_name so we can easily get rid of them if we have to.

"Getting rid" of apps installed from source is not so difficult if the developer was considerate enough to include a "make uninstall" target in his Makefile (and several do this) ... if not ... add one yourself ... send the developer a patch ... contribute to the community. Or, alternatively, redirect the output of "make install" to a textfile so you have a list of files and installation directories. A simple edit will turn your textfile into an uninstall script.

Just my US$0.02, one admin to another.

Re:Luke, use the source...

[coats]

Really, there is nothing to difficult about:

./configure
make
su
make install

Try that on a fully-configured development-server configuration RedHat 7.1 machine with the AbiWord 1.0.x .src.tar.gz and tell me what to do when configure says "gcc does not work on this machine"... and you know damned well that gcc does work and you've been building stuff with it for years!

Re:Luke, use the source...

[Wdomburg]

It's really not that hard to figure out:

rpm --rebuild whatever.srpm

Your shiny new binary RPM(s) will be in whatever the system path is for RPM (on Red Hat it's /usr/src/redhat/RPMS).

Or alternately, you can

rpm -i whatever.srpm
cd /usr/src/redhat
rpm -ba SPECS/whatever.spec

And the binary RPMs will end up in the same place. Plus with that method is you can edit the spec file for customization.

Most people who gripe about RPMs being too hard probably have never looked at the spec files before - all they are is some meta information and a shell script that builds the program. Building from scratch may be hairy for a new user, but customizing an existing package is REALLY easy; usually it's just a matter of looking for a line starting with "./configure" and adding the options you want after that.

Why go through the trouble when you could do it from source? It is much much easier for replicated installs, you don't have to worry about stray files lying all over the place, its easy to tag files as being configuration so they don't get overwritten, etc, etc.

Matt

Re:Luke, use the source...

[simm_s]

Yeah and what happens when make uninstall does not work?

Gentoo is a giant step, too long for mere mortals

[isdnip]

I fully appreciate the author's sympathies. I'm used to replacing RPM-based distros; just last night I burned a new Mandrake Cooker so I could try it. KDE3.01 et al are just too hard to get right using RPM upgrades. But then he mentions gentoo...

...which I have also tried to install. Trouble is, gentoo has *no* installer, past the kernel stage. I can't even get sound to work, becuase my mobo sound chip isn't in their ALSA tree. I'm sure there's a way to do it but they don't tell you. Gentoo users are typically, I suppose, the type of Unix experts who have no trouble figuring out which driver goes where. But gentoo lays things out differently from RedHat (etc.) so I can't just copy their /etc (etc.!) files.

If gentoo had a decent installer, not necessarily as "friendly" as Mandrake (more flexibility is a plus) but which could guide all the files into the right places, then it might be a killer. For now, it's a cult for experts. But I don't see why a binary-based (or at least partially binary-based) distro couldn't use an apt-get or portage-like system when needed, without requiring gentoo's exceptional knowledge (well, that's what it feels like to the "n00b" whose recent Linux experience is mostly RH and Mdk) of the distro's layout.

Hints...

[n1k0]

From the article...

> On the other hand, have you noticed how hard it is to find Debian ISO images?

http://www.linuxiso.org - I can't believe you've never heard of this place. They've had Debian ISOs since I first learned of them.

I admit, debian.org's ISO download wizard is garbage, but I think they're trying to save bandwidth by having you download what you need instead of the entire ISO (there's no reason you need to install every package in the ISO).

niko

Re:Hints...

[LinuxHam]

the old ISO construction method was a complete pile of crap. no matter which mirrors I tried, SOMETHING was always missing.. usually in the docs section.

Their new util, jigdo, worked just fine first time here. Unfortunately, from what I could tell, it doesn't really save bandwidth by letting you fine tune the download. Perhaps you're referring to the ISO for a cd-based network installer.

depends

[diamondc]

I use Debian Unstable at home because I always want the latest and greatest software and I already know how to fix 95% of the apt/deb problems that occasionally happen. At work, I use Debian Stable because I never want to touch the server after it's been configured and tweaked.

The good thing about RedHat and Mandrake to some extent is that they do good testing on the RPMS on the cds. I figure they don't expect people to install some 3rd party RPM off the net.

There is nothing wrong with RPMs. Only packagers.

[Ranger Rick]

The author mentions, "On the other hand, have you noticed how hard it is to find Debian ISO images?" Yes, Debian is very upgradable, but that has nothing to do with the percieved shortcomings of the RPM package format.

The RPM format is nearly identical feature-for-feature with Debian's dpkg. RPM's upgradability has nothing to do with technical issues. There are three things that make Debian's package management so much better than RPM-based distributions.

The first is, there are way more distributions based on RPM packages than deb's. It's not suprising that some of them are more incompatible with each other than any debian release has ever been. Sure, there are many more people with hairy backs in the US than there are in Lichtenstein, that doesn't mean that living in the US causes hair to grow on your back. He is inferring causality where it doesn't exist.

Second, APT. APT is what makes debian's package management so smart, not dpkg. And, in fact, this isn't a reason at all. APT now works with RPM packages, and when dependencies are properly configured, it is every bit as good as it is on debian. You can make an APT repository with RedHat's "rawhide" distribution and upgrade daily if you want. You won't have any more upgrade issues than you would running debian unstable. It may break occasionally, but it's when large changes happen. The exact same thing happens on the debian side.

Third, Debian is fanatical about consistency. Most debian packagers manage maybe three or four packages (there are exceptions, of course). When you devote all of your free time to just a few things like that, a lot of attention is payed to details. This is what truly makes Debian's package management so freakin' clean. It has nothing to do with technology, it has everything to do with each maintainer hand-crafting dependencies and build options very carefully.

The thing that pretty much any of the RPM-based distributions is truly missing is the equivalent of the Debian package maintainer guidelines, and a culture that enforces it. If that existed, RedHat would be just as consistent and upgradable as debian.

I use RedHat and I'm careful about what I put on my system, and I never run into upgrade issues. If I'm going to install something that is for a distribution other than mine, I build from .src.rpm's instead of binaries and I *know* it's compatible with my install. Someday, if packagers stop being idiots and using shortcuts, I won't have to. Everything will resolve properly in the huge worldwide-apt-rpm-uber-archive.

Okay, here

[0x0d0a]

I hate it! You need to compile a new RPM for each platform

What we needis a smart .tar.gz2 package which detects what OS your using, and compiles and installs automagically with an easy to use gui and a powerful cli interface

Well, hell.

------

#!/bin/sh
# Demonstration that RPM ain't all that bad
# Copyright 2002, 0x0d0a
# This code placed under the GPL
# Should compute proper buildroot, etc
# Be damn sure not to set buildroot to /
# or something similar -- rm -rf would
# then suck severely
# Set our_rpm_buildroot appropriately
# Usage: mybuildrpm.sh foo.tar.bz2
our_rpm_buildroot=/usr/src/redhat
ni ce -20 rpm -tb "$@" && rpm -Uvh `find $our_rpm_buildroot -type f` && rm -f `find $our_rpm_buildroot -type f`

-----
Okay, I grant that there's no gui, but you get all the many CLI options of RPM. Voila!

People love to bash RPM, but it's a pretty sweet system (except the move to the newer underlying dbfile...screw transactions, I can always rebuild the database if it gets corrupted and it takes *much* longer to install and query than things did back with rpm 3.0). If it's too simple for you, it's really easy to use it as a back end and slap something on top of it.

Note: this is a one minute hack and may not even run, much less be safe for your system...it's an example, not intended to be used. And hell, running random stuff from people on Slashdot as root just isn't a great idea. :-)

Re:Okay, here

[alfredo]

apt-get, and Fink are fine with me. RPM too often leads to dependency hell.

BTW, YellowDog Linux now has apt-get as alternative to YUP.

single point of failure

[Futurepower(R)]

The registry in Windows creates a single point of failure. The point of the registry seems to be copy protection. The registry contains incomprehensible data. It is an area meant to be outside the user's control.

Re:single point of failure

[Graymalkin]

Well I'm sure glad Linux uses /etc to store confiruation data. Having 50 different styles of configuration files sure does make one's life easier.

Re:single point of failure

[0x0d0a]

The syntax of UNIX config files is pretty standard (barring the occasional ugly misfit like sendmail -- use postfix instead).

And all the Windows registry does is give a standard format for storing individual values (how should I store a string, how should I store a DWORD) and provide a hierarchy. It says nothing about format or structure within a single app.

If you want to turn on, say, mail relaying in postfix on Linux, then you look for the entry called mail_relay (or whatever) that's commented out and contains a helpful set of comments right above the config entry. On Windows, the equivalent is to go into the registry to some unspecified key, create an unspecified value there and then set it to some unspecified value.

Of course, most people just use a front end on Windows -- like a preferences or options dialog -- because the registry is next to useless to actually interact with. You can do the same thing on Linux, which is done by GNOME and friends to make things more convenient for computer novices.

Also, if the Windows registry gets corrupted, you have a big problem. If a single text format config file gets corrupted, you can probably fix it yourself. If you can't...well, it's a single file down the drain. Reconfigure that single app. Your entire system doesn't become unbootable, a la Windows.

Re:single point of failure

[Graymalkin]

Registry values aren't unspecified some you just have to play with at first. It isn't any simpler or complex than /etc config files. The point of the post was to point out the irony and retardedness of praising /etc as the end all be all of program configuration. A single configuration point is at times much less confusing than people writing programs with no standard configuration method.

Re:single point of failure

[Graymalkin]

Compared to the .ini hell of MS-DOS and Windows 3.1 the registry was a huge improvement in structure and style. Now it isn't the greatest of ideas in the world because the OS and software available for it is much more complex than for Windows 95. Having a bunch of text files in /etc is nice on the metadata front, any .conf file I've ever edited has huge chunks of commented lines I've added to remind me in a pinch what options to what.

A real badass scheme is OSX's XML based conf files for Cocoa applications. They're structured and easy to work with from a programming point of view, the programmer is sheltered from actually dealing with the files. They can also be tossed into a lightweight text editor and have hackish magic performed on them. Netscape/Mozilla's .js config files aren't to terrible to work with either. Too bad neither of these will ever become an accepted standard in any Linux software ever. Linux is carrying too much cruft from old paradigms for its own good for that to happen.

Re:Solaris packaging

[mindstrm]

Okay.
What features of the solaris package management and/or solaris packages themselves do you want to see? Because if it's just about nice, neat clean packages that install trouble free.... well, let's just say it's entirely easy to produce a solaris package that sucks.

The point is.. RPM is not the culprit; multiple vendors using the same package but systems that are rather different sucks.

debian packages work well because the debian world is rather focused. Because we ensure that all dependencies can also be met from debian packages in the same distirubtion, etcetera.

If you use redhat and only redhat official packages, it works great too (well, insomuch as redhat can work great)

Where are the programs?

[Anonymous Coward]

The first time I installed an RPM which was not included on the CDs, I was wondering badly what happened.

Where was the program?
It was not in the K menu.
It was not on the desktop.
It was lost.

So I thought something went wrong and installed the RPM once more but it claimed the rpm was already installed.

I eventually realized it was indeed installed but the installer did not:
- ask me whether to put an entry in the menu
- decided for itself where the files were supposed to be

Never mind that I wanted the files to be in my home directory.
Never mind that I had no clue what the primary program name was.

There were dozens and dozens of other files in the RPM, mind you. It is not easy to determine what is a binary and what is not when you have just installed Linux for the first time.

And this does not even touch the subject of dependency hell. I have wanted to install several programs only to give up because of a huge number of dependencies.

Re:Where are the programs?

[0x0d0a]

The first time I installed an RPM which was not included on the CDs, I was wondering badly what happened

Just do this:

rpm -Uvh foo.i386.rpm

Now the RPM is installed...now we want to see the program name.

rpm -ql foo|grep bin

Voila!

Finally, dependencies are not the fault of the RPM system. If you took the raw binaries and plopped them on your system, you'd have the same dependencies...you just wouldn't be warned about them, and programs would malfunction, not launch because the linker would give a warning, etc.

RPM warns you of dependencies to *help* you, not to hurt you.

You can always install with --nodeps, but usually, unless you know what you're doing, you're better off trusting RPM.

Re:Where are the programs?

[Accelerated Joe]

You wrote:

Where was the program?
It was not in the K menu.
It was not on the desktop.
It was lost.

Modern poetry?

Anyways, I'd just love to point out that debian has a system in place for this. There is a beautiful program called update-menus. Almost every debian package supports it, and it allows menus to be consistent through every desktop environment.

Re:Where are the programs?

[Accelerated Joe]

update-menus is in the "menu" package. Once, I forgot to install it, and I had a terrible time trying to figure out why my menus were all horrible!

It usually gets installed in the installation process, unless you're trying to do something weird, like doing the initial install with apt-get instead of dselect.

Re:Gentoo is a giant step, too long for mere morta

[handsomepete]

There's been quite a discussion on the installer issue in the Gentoo forums (the thread can be found here). The general consesus from the users seems to be that they like Gentoo being kind of a "niche" distro. If the idea of the source based distro really appeals to you, I would suggest giving it another go and leaning very heavily on the forums (if you need to). Gentoo's Forums have the most helpful and friendly user base I have ever seen on the internet. I have yet to see a single person give a n00b a hard time (outside of the occasional rtfm...). I realize that it's not for everyone and that it takes a little bit of work, but I think Gentoo is definitely worth it after the dust settles. It's nice to install an OS and feel like you actually accomplished something.

Oh yeah, and I don't like RPMs.

Backward compatiblity?

[k98sven]

Many of you will have remembered that the RPM Package Manager went from 3.x to 4.x without backward compatibility and upgrading it was an arduous task, to put it mildly.
Aw, it ain't that bad. I found myself changing version numbers in RPMs with a hex editor.

Strangely, it actually worked just fine.

Sometimes I think they break backward compatiblity just for the heck of it.

Well, DUH! :{D

[Gryffin]

While I agree with the thrust of the article, it would be much more persuasive with a little more meat behind it.

"There is at least one distribution (ESware) that has moved from RPMs do DEBs, but I don't know of any movement in the opposite direction."

A little research into just how many distros have migrated one way or the other in, say, the last five years would be instructive.

"Similarly, there are many users who have moved from RPMs to DEBs, but very few who have chosen the opposite path."

This statement is pivotal to the article, but is completely unsupported by any hard numbers, and comes off overly broad. (Surely there must be have been SOME attempts to determine market share of the major distros?) Maybe you don't know anyone who's gone the other way, but I'm sure it happens.

That said, there's a lotta truth in this article. After a couple years of struggling with RPM Hell on Red Hat and later Mandrake & Yellow Dog, I've recently decided to switch over to FreeBSD (ports, yum!) on my server and Debian on the workstation.

Oh, as an aside, there's an implementation of deb/apt for Mac OS X and Darwin, called fink. Fink supports both binaries with apt-get/dselect, and source installs with their own ports-like tool. I know a number of people who run traditional Linux/Unix progs, including X Windows, The Gimp, KDE, etc., side-by-side with their regular Mac apps. Oh so very cool.

Source-based and minimalist distributions

[fw3]

I've long preferred slackware for it's approach which basically looks like BSD both for package management and operatoins interface.

For linuxes the various source-based approaches are becoming more popular / solid. In addition to Gentoo, there are Sorcerer Linux and two working forks (Lunar and Source Mage) see summary.

As pointed out in a comment above this one, when RPM snafus (often) you can usually build from source with minimal effort. Unfortunatley that's not true for RPM itself, which I have found to be a major pita to build from sources, or things like Gnome / E17.

Vendor unixes (Solaris, AIX, HPUX) put a lot of effort into correctly managing dependency checking. Part of their solution, however is in building their own versions of sources and staying as much as 2-3 years behind the current-releases of any given package.

RPM is a far cry from the vendor unix approaches, part of which I'm sure is that it's trying to do a much harder task on a less well defined base platform (random hardware).

Try building RPM from redhat's sources sometime, use the force you're gonna need it! That alone suggests to me that this is not in 'reality' an opensource project. A GPL license for software that doesn't build with './configure; make' doesn't seem like an effective oss project to me.

Re:Source-based and minimalist distributions

[GigsVT]

You mention major vendors. I have a story that makes anything RPM based look like cake.

We bought the MIPSPro compiler for our Origin 2000. It came on something like 6 or 7 CDs. No problem, it's got a nice package manager and all, right?

Heh. So we put the first CD in and told the package manager to install the compiler. It churned a while, then came up with a list of about 30 dependancies that were broken. It then instructed us to insert CD after CD, swapping back and forth between compiler, OS, and Library CDs for at least two hours, I'm talking hundreds of swaps.

We finally got it installed after flipping CDs for two hours, and then upon running it, it informed us that we only got the 2CPU version, when our computer had 4CPUs, so we were going to have to get a new license.

The new license was an extra $1000 or so (the 2 CPU version was already $600). We said screw it, send that piece of shit back to our vendor, and just left the unusable binaries laying around the hard disk, we had already wasted enough time installing the damn thing.

We installed gcc, and just used it instead. Took all of 10 minutes to set up.

SGI still tries to bill us for "support" on the compiler ($300 a year or so). We have to tell them to shit in their hat every year.

Re:Gentoo is a giant step, too long for mere morta

[mindstrm]

Debian.

Look A basic install, though perhaps not quite as bare as gentoo, is really bare. Really light.

You end up, with a minimal configuration, with teh bare minimum you need to boot, get a console, and install more packages over the network.

Then it's a matter of adding packages as you see fit... which is entirely too easy.

to get here, just skip the package selection and/or task selection (where you choose either individual packages, or in beginner mode, what kind of machine it's going to be, development, server, etc.)

I do every debian machine for every reason this way. I love it especially becaues it leaves me with a light, clean system every time.

One of the reasons behind Gentoo is probably one of the reasons why people used to love Slackware (heh, I guess some still do). Because you had to do things the old fashioned way. Get source, comipile, install where you saw fit. You had to actually learn how things work.

I can say that, in having ot mess with early, early version of linux I learned more about how unix works than any other unix I've used. Having to actually figure out, either by reading, or trial and error, what file goes a LONG way towards being able to work multi-platform.

Just got ADSL, Just had a nightmare with packages

[oliverthered]

I aggree,
I installed mandrake 8.2 a while ago, since then there have been a lot of 1.0 releases out.
OpenOffice,
Mozilla,
KDE (3.0.1)
etc....
But mandrakes packages have some rediculios deps, to install KDE 3.0.1 from there cooker(dev), it wanted me to update thinkgs like unixODBC and MYSQl,I don't wan't mySQL and call me stupid but obdc's a protocol!!! and i dont think the latest unixODBC changes that , why the hell have they put such non-granular pagkages togeter, if i had a release plan like that at work I'd probably be out of a job.
The RPM tree locations in mandrake used to be different from the package defaults which ment i could'nt install wines RPM and know i wasn't going to screw up package management some time in the future.

Dependencies of RPM's really need sorting out, and there should be no reason why i can install a suse package on redhat (so long as they both follow LSB!!)

grrrrrrrrrrrrrrrr

RPM not the problem..

[reflective recursion]

in itself. The problem is not using the hierarchal file system in a coherent way. In addition to that problem we have way too many files nowadays. When package contents mix with one another.. well I'm sure you've had Chem. 101.

This article wants solutions, so here is mine:
Make packages a seperate directory. Just like good old DOS days--where every program lived by itself in a directory. _All_ package contents go in this special directory. Then you have the problem of per-user configuration. This is incredibly simple. Have a directory in each user's directory which _mirrors_ the package directory. Each package directory should be unique (i.e. MyProgram v1.0 lives in a different directory than MyProgram v1.1). Dependencies would be much easier this way since you would only depend on a _directory_ existing. Moving packages would simply be a matter of packing up the directory and taking it wherever.

In any case, software is _package_ based. Why do we still throw library files from different packages together in the same directory?! When you want to remove a package you have to rely on broken package managers, or hunt down every file which goes with a package. We should be able to completely remove software by simply removing a directory. I've heard MacOS does this, why can't Linux?

Re:RPM not the problem..

[Fluffy the Cat]

Why do we still throw library files from different packages together in the same directory?!

Mostly because that's the point of libraries. Libraries allow code to be reused between applications - sticking them in application specific locations makes it somewhat harder for application A to use library B.

Re:RPM not the problem..

[reflective recursion]

I don't know if you've noticed lately, but libraries _are_ packages today. GTK+ for example. Qt, ncurses, etc. And if a package creates a _new_ library, then not many people are going to depend on it. And if they _do_ depend on it, they might as well depend on the entire package being there--since the library is a _part_ of the package.

The idea of sharing arbitrary library code is a failed experiment. If I create MyProgram and then I create MyProgramLib.. not many people will ever use the library. The only case they _will_ use that library is if I _package_ it seperately, and make it a coherent entity itself--with documentation. This is why, IMO, going package-only and dropping the various */lib directories can only be a Good Thing. And this is how Red Hat, etc. do it today. They create dependencies between _packages_. If I create an app in RPM format that needs, say libgimp, then my package will depend on the _entire_ gimp package being installed. Not just libgimp. Why not just handle packages naturally?

I'd also like to point out the benefits of doing this:

- Package corruption will be detected immediately. When something depends on a package and a file is missing or corrupt then the package can be determined corrupt.

- Dependencies handled naturally. When a program complains that a file doesn't exist, I can pinpoint _exactly_ which package the file is in and can simply reinstall the package. No need to hunt down which file belongs to which package.

Re:RPM not the problem..

[demaria]

Congratulations! You just described OS X. :-D

All files for the package is in directory /Application/$APPNAME (you can put them anywhere in reality. Users can also install their own programs in their homedir). A special flag makes this directory appear like a single file to the user interface. Double click and it launches. Just drag to the trash to delete it. Not only does this directory hold the executable, but also library files, help files, and everything else. User config files are in the user's home directory in ~/Library/Preferences.

/System is for the OS. It contains library files and all sorts of other stuff for the OS and apps. However, Apple's guidelines state that programs can not modify or add to /System. So if you're running MacOS X 10.1.5, you will have the same /System as someone else running 10.1.5 (Apple once or twice had a security update without incrementing the version number but that was just to patch security holes). If a program wants to use libraries not in /System the package needs to include it itself - there are no dependencies in OS X. This severe Apple control works great for Macs, but I don't know if Linux users would stand for Redhat et al dictating their /lib.

Re:RPM not the problem..

[captaineo]

One of the flaws of a shared library directory is that free software developers are notoriously bad at preserving backwards- and forwards- compatibility between different library versions. It does no good to have a single libfoo.so when one of its users relies on a bug in an old version of the library, and another user won't run because it needs a symbol from a newer version.

I can agree with having a common set of very basic libraries - libc, libX11, libgtk, etc - that are used by many programs and whose interfaces have been NAILED DOWN. But pretty much anything else is just too exotic and risky to justify sharing libs.

I am currently working on a commercial software package for Linux, and we firmly plan to link everything statically, except for libc. (we have even considered bypassing glibc - which is bloated and forwards-incompatible - and making the kernel itself our only dependency).

This point may not move you, but Windows has done fine for many years, and over there hardly any "common" libraries exist aside from the stable MS-provided ones (user32.dll, comctrl32.dll, etc...). This may be because Windows developers tend to scream and shout very loudly when somebody breaks the API of a shared library...

Re:RPM not the problem..

[cgleba]

"The problem is not using the hierarchal file system in a coherent way."

I hear this argument every time package managment is discussed on slashdot and every time I bite my tongue.

The current system of /bin,/lib,/etc, etc. has many many advantages over the "good old DOS days" -- ESPECIALLY when you start mixing in NFS and automount. Some examples:

* all SHARED libraries are in the same place. That way the dynamic linbker does not need to do a ridiculous path search to find a library

* all binaries are in 3 -4 places -- that way you don't need a massive PATH variable like 'the good old DOS days'

* because the files are sorted by type, you can do all types of neat things. Let's say for instance that you have Solaris SPARC, Tru64 Alpha and x86 Linux boxes all sharing a single NFS server. Now the /etc directory is architecture and OS independant so you can share the same directory accross all three. The /var directory is achitecture independant but depending on your set-up it will probably not be OS depandant. Thus you can discern the differences between the OSs yourself and set up an automount variable to mount the proper version per OS. The /lib and /bin directories are both OS and architecture dependant. In that case you must set automount variables for OS and arch and mount different dirs for each.

Let's say that you install emacs network-wide. You share the same config accross all your NFS clients and just make different /bin and /lib for each. You need to change some defult configs for all the clients? Voila, just edit one config file! Could you share one program accross multiple machines, architectures and OSes in the 'good old DOS days'? Could you immediately upgrade 65 workstations to the newest version of a program without reboots and only use 1/65th the space (aka one copy) in the 'good old DOS days'?

* Because the files are sorted BY TYPE you can do all types of neat optimization and security things. You can mount /usr ro. You can optimize your RAID array for fast read and writes in the /var mount while optimizing /usr, *lib and *bin for fast reads, etc.

'the good old DOS' system was good for what it was used for -- a small system for one user with a few programs and didn't need any optimization. The heierarchal system is a lot better here used as a multi-user, muti-tasking shared-library networked OS with hundreds of programs.

Now if you hate the heierarchal system that much, you can do what SCO OpenServer does -- install all the files into each 'program directory' and then make symbolic links into the heierarchal system. It would be VERY easy to do -- just write a script to query your RPM database for what files are in each package, move all the files for that package into its own directory and then make a symbolic link for each file moved back to the hierarchal system.

SCO liked the 'good old DOS days' also. The problem with OpenServer and all those symbolic links, though, is that resolving the symbolic links by the dynamic linker, the shell, the programs, etc actually was pretty expensive and gave a decent hit to filesystem performance. Furthermore it made NFS-mounted trees hell and you could not do all the neat optimization and security stuff that I mentioned above.

In summary, the heierarchal system is by far easier to manage for performance, security and for centralization. It is tougher to manage for "adding / removing" programs. The former highly outweighs the latter, expecially since you have package databases to help tell you where all the files are. Learn to use your package managment system.

The bulk of this article and thread seem to be once again people bitching about RPM dependency hell. The solution to that is download the source rpms and then do a rpm --rebuild [source RPM] then a rpm -i [/usr/src/RPM/RPMS/i686/[name of RPM built]. That solves 96% of all your problems and still maintains your RPM database. config, make works too, but it throws you back into the chaotic world of no package managment and thus completely defeats the purpose of RPMs.

Have a nice day!

Re:RPM not the problem..

[Ian Lance Taylor]

Look at /package.

Re:RPM not the problem..

[reflective recursion]

I think you missed the point.. I said _arbitrary_. libc is a central library. The idea behind shoving all libraries into a directory is because of the possibility someone may use a library. This is a theory and in practice you rarely use libraries which are not well defined or even their own seperate package entity.

Re:RPM not the problem..

[daniel2000]

you might want to check this software for linux:

http://rox.sourceforge.net/

Some background (from the website)

The ROX Desktop, however, is based around the file system. It's core component is ROX-Filer, a powerful graphical file manager which, in addition to being a pretty neat filer in its own right (IMHO!), provides a couple of extra features which allow it to solve the above problems.

The first of these features is support for `Application Directories'. An application directory is a directory which contains an entire application - its documentation, binaries, source code and so on. When you open an application directory in the filer the application is run. This has some interesting implications:

Installing an application is the same as copying a directory. No need for special setup programs (or root access). For example, let's suppose that your friend has the latest version of ROX-Filer and you want it. She simply copies the directory onto a floppy disk and hands it to you. You can run the program directory from the floppy if you want, or you can drag it onto your hard disk to `install' it.
Uninstalling is the same as deleting a directory.
Want to install two different versions of the same application? Just copy them to different directories on your hard disk.
To read an application's help usually involves hunting around for man-pages, info pages, directories in /usr/doc and so on. With an application directory the help is inside it - just choose Help from the filer menu to see it (all this does is to open a subdirectory inside the application called 'Help' - simple, eh?).
There is no need for a separate filer and application launcher. The filer does both, and you always know where your programs are.

Re:RPM not the problem..

[captaineo]

Yes, I understand that most prudent Windows developers ship a specific version of MFC.dll and msvcrt.dll. Not all Windows DLLs have remained as compatible as the core...

But you never see anyone replacing gdi32 or advapi32. On the other hand, on Linux I've been bitten several times by incompatibilities between glibc 2.1 and 2.2. (heck even the man pages admit incompatibilities - see 'snprintf' and 'mkstemp'). To me this is akin to a link failure on 'malloc' or 'printf'. It just shouldn't happen in this day and age! I *should* be able to ship a program dynamically linked against GTK, or libtiff, or whatever, and just have it work, same as I can link against user32.dll and know that CreateWindow will act like it should.

I think Microsoft is taking a step in the right direction with .NET assemblies (and their checksummed APIs). A major reason for DLL breakage in the free software world is the lack of any sort of warning that you've broken the API; something as subtle as adding a new virtual function to a C++ class will break binary compatibility... It would be great to have a program that could flag things like this.

If you want to have different versions of a shared library, that's fine, just as long as it's a purely one-dimensional, monotonically increasing measure (i.e. if I declare my program depends on version 4 of libfoo.so, it should be guaranteed to work with version 4, 5, and 50, but not necessarily 1, 2, or 3). But sadly most libraries evolve in such a way that you have to place a ceiling as well as a floor on the appropriate version for your program =).

My favorite approach is to get the API right the first time, and promise never to change it. (yeah, throw release early, release often out the window)... I have actually achieved this with my dv1394 kernel driver - the API was frozen on day one of release, and it has never changed. It took some hard work to convince myself that the API was sufficient for all possible uses, but it was definitely worth it to avoid version skew altogether.

Incidentally, I have to give credit to the developers of GTK. I have been following them through the 2.0 release process, and it seems like they are one of the first free software projects to really take library compatibility seriously.

Re:RPM not the problem..

[reflective recursion]

There are tons of problems with Linux file systems (and general *ix).

all SHARED libraries are in the same place. That way the dynamic linbker does not need to do a ridiculous path search to find a library

This is a convenience for the linker, though. Not one for the user or developer. We should not have to sacrifice simplicity to make the linker simple. And if we have the hierarchy and system that I have in mind this won't be a problem at all, since the linker today uses a cache and doesn't scan the directories at all (for the most part, unless you ldconfig).

all binaries are in 3 -4 places -- that way you don't need a massive PATH variable like 'the good old DOS days'

But there is where you are wrong.
/bin
/sbin
/usr/bin
/usr/local/bin
/usr/sbin
/usr/local/sbin
/usr/X11/bin
/var/lib/apache (only god knows how it got there..)
/opt/kde/bin (NOTE this)
/opt/gnome/bin (and this)
Then IBM Java needs added to the $PATH. I also remember Qt having issues with this and needing added to the path. And typically I add a /home/*user*/bin which I place personal scripts that I use. The PATH issue is still there. I'm willing to bet that there is a much cleaner and better way to find executable files than what we use today. Perhaps a caching method would do well.

I don't see your point about NFS, other than /etc is for the most part system-independent. Perhaps package+configuration directory would be good enough? But, ideally configuration data would remain with the package. That way you can simply move a directory and the package will become persistent. With my method you could share one program across multiple machines. Say you have this:

/package/my-application-1.0/

You can use NFS and the entire package will be available remotely. You are really taking my usage of DOS way too literal (and in a different context). The simplicity of one program to one directory is what I meant by "good old DOS days." Not that DOS could be used via NFS in the way you mentioned.

'the good old DOS' system was good for what it was used for -- a small system for one user with a few programs and didn't need any optimization. The heierarchal system is a lot better here used as a multi-user, muti-tasking shared-library networked OS with hundreds of programs.

And I would say to that, that much of the complexity of Linux (general *ix) is invented and not actual complexity with a purpose. The multi-user and multitasking issues are simple to tackle w/ the system I described. The shared-library issue would need work, but it is very doable.

Now if you hate the heierarchal system that much, you can do what SCO OpenServer does -- install all the files into each 'program directory' and then make symbolic links

Erm.. but then we are all still dependent upon the Linux hierarchy, now aren't we? It might be useful for me (after tons of work making every package fit my system), but it doesn't do a thing for anyone else. Which I think was the purpose of the article..

[...] expecially since you have package databases to help tell you where all the files are

It could very well be the other way around (databases telling where packages are).

The bulk of this article and thread seem to be once again people bitching about RPM dependency hell.

No, not RPM dependency hell. Dependency hell in general. Which is easier to depend on: one package, or a library in /usr/local/lib, 50 header files in /usr/include/*lib-name*, a config script that brings it all together in /usr/local/bin? Dependency is not just a shared-library issue, either (as I mentioned with header files). It is much bigger and in the future will be much, much more nasty.

If we don't clean the crap up now we are in for a very very nasty environment later. Call it pollution of the OS, if you want. The Linux I use today is much less organized than even the one I used 4 years ago. And it is getting worse.. such as the /opt/kde and /opt/gnome directories which some distributions are now doing. This tells me there is something seriously wrong when you must recreate the file system hierarchy in /opt just to allow simple removal of packages (or in this case, a complete desktop system).

Re:RPM not the problem..

[Tim C]

If I create an app in RPM format that needs, say libgimp, then my package will depend on the _entire_ gimp package being installed.

Which, imho, is a real pain. Mandrake's KDevelop package "requires" Gimp to be installed. I didn't really want another 20+meg of data on my drive that I'm unlikely to ever use, so I used the --nodeps option to rpm - and it worked just fine. I can only assume that KDevelop requires icon editing software, or something, rather than the Gimp itself.

Another example is the development version of Qt3 that comes with the Mandrake KDE3 packages. It requires the MySQL and Postgres libraries, amongst others, which in turn require the rest of their respective packages. If you want to compile KDE3 apps on a Mandrake (8.2) system, you have to install not one but two databases.

Follow that sort of procedure for everything you want to install, and the amount of data that is installed that you don't want could well be larger than the amount that you do. I know that disk space is cheap these days, but it's still not free.

Cheers,

Tim

Automaticness

[Apreche]

What we need is to get rid of the entire packaging system all together. I know I'll probably get toasted for this. But software should install in linux the same way it installs in windows. There should be one file, like setup.exe. I should take that file, execute it, it will ask me what parts of the software I want, and where I want to put it, etc. From my experience there are two pieces of software for linux that do this, the Tribes 2 server, and Mozilla.
The entire packaging system is just a pain in the butt. This depends on that depends on this. urpmi, rpm -i, rpm -U, things not working with no explanation. In Windows I never have to worry about one thign relying on another thing. Because just about everything uses DirectX. And directX COMES WITH anything that uses it. And it has a simple graphical isntallation.
There should be one downloadable file for each piece of software I want. It should install on its own, on any linux machine, easily and graphically. And all of my library packages like glibc, etc. Should transparently update themselves to the newest versions all the time. I dont' want to have to worry about that stuff. Drivers in linux are incredibly difficult to install. They should become a simple right click, install driver. Done. I want all that other crap taken care of for me. I don't have time to change paths in config files, tinker with code, look up crazy commands and recompile crap.
I feel the package system is the real place in which linux fails. Most distros, lets use Mandrake as an example, have graphical easy installations. But when you get to the package selection phase you're stuck forever weeding through thousands and thousands of checkboxes. Not cool.
One piece of software should be one checkbox. KDE alone has like 20+ rpm files. There should be one file. KDE3setup.exe.
You know that installshield that almsot every piece of windows software has? Maybe someone could code that for linux. I would, but I have no idea how to do something like that. But I know someone reading this does. And if you want to save your open source os, I suggest you do.

Re:Automaticness

[0x0d0a]

But software should install in linux the same way that it installs in windows. There should be one file, like setup.exe

No. I'm going to have to strongly disagree here.

Your complaint is valid and reasonable, and unfortunately ignored by the Linux community, but your solution is not.

Your complaint is that you want a simple *user interface* to install large pieces of software. This is reasonable. There is not front end that I know of that's widely used that chooses a reasonable subset of packages in a large software package (like GNOME) to install. You have to select all the packages in the system, one by one. That's fair, and should be addressed.

Your solution, however, is not a good idea. The Windows method of having a single installer puts you at the mercy of sitting down at the machine and actually clicking and installing stuff. It puts you at the mercy of what features are supported in the installer, how old the installer is, etc. The Linux (well, RPM/deb) approach is to separate the program from the packages. Upgrade the program, you get more features/bugfixes. You can install every piece of software remotely (ever watch Windows administrators run around installing a new piece of software on a network? What could be done securely on Linux with a bit of setup with sshd and public keys and then a single command to install software on every machine involves the IT people running around to each machine and clicking "OK" and watching progress bars). If you bundled all these packages into one large package, and someone doesn't *need* all of them, they need to download extra data. If you need to install, say, GNOME on every machine on the network, you only have to transfer the few RPMs *your* users actually require.

The solution is a fix to the front end, not to the architecture of the system. We need a single checkbox that installs a good default subset of packages for a large software package. The "GNOME" checkbox would install gnome-core, gnome-libs, etc, but probably not glade. The Linux rpm installation architecture is superior to the Windows installshield architecture -- now let's make the user experience as nice for novices.

Re:Automaticness

[Mongoose]

You must be new to UNIX like systems. You see there is a reason we don't have 50MB executables from all the static linking and DLL hell. We use shared objects between all apps to save disk space, development time, and main memory. I see you complaining about rpms, so maybe you should try a distro like Debian GNU/Linux, and expand your horizons.

For example if we did shar archives ( what you want with your 'setup.exe' ), then you'd have to install all of KDE to just get QT libs. You'd have to install all of GNOME to get gtk+. You see why that's piss poor way to do things just from a packaging standpoint even if you don't understand the techincal aspects? Also versioning would be impossible to support. Versioning is allowing multiple libs to stay on the system without conflicting, so apps can use various versions as they choose. To support versioning you'd have to have N number of KDE installs.

I don't see how that post go modded up, when it's so misinformed... oh this is slashdot.

Re:Automaticness

[Apreche]

You have a valid point that it sucks to run around clicking ok on every machine. But if you are running a large network and you have any brains you shouldn't have to do that. You install the software on one machine and ghost it. And most large applications in windows have install over network options, where the administrator can install one piece of software on thousands of machines from one terminal.
As for downloading extra data, that isn't a prolem either. Look at somethign like quick time. You download a very small install file. Then you select which componenets of QuickTime you want. It downloads those components and installs them. The best part is that the components have names in english. Such as Quick Time Virtual Reality
Not QT-1.555354-V.r.rpm SO you can easily understand what components you are installing.

Re:Automaticness

[Apreche]

I don't know what you people are complaining about with dllhell. Conflicting DLL files or old dlls replacing new ones is a result of poor system administration. At least the software you are installing knows what dlls it needs, and it comes with them, rather than me trying to figure out 10000 dependencies, what they are, how to install them, etc. Deiban I would use, but the installer for the distro sucks. It's so hard to install debian its not worth my time.
I don't see why you would have to install all of KDE to get QTlibs. When you runs setup.exe in windows there is always a custom button that allows you to select which components you wish to install.
And versioning sounds horrible to me. Why would you keep multiple versions of a library on your system? That's a poorly designed system to me. Only the newest most up to date library should need to be on the system. If the libraries aren't backwards compatible or software isn't forwards compatible that is another design flaw.

Re:Automaticness

[rossz]

Take a look at InstallAnywhere at ZeroG. This is a java based install engine that runs on any platform that supports java. I've used version 4.x professionally and like it, though it does have a few problems (doesn't everything?). Version 5.0 was just released but I haven't taken a look at it yet. Hopefully, they listened to the suggestions I sent to them and incorporated them into this version.

The installer had both a graphic and console interface. My major complaint was regarding the console interface. You basically had to write all you steps twice, once for the GUI and once for the console. This was unnecessary work and error prone.

Re:Automaticness

[Webmonger]

In Debian, the approach to this problem is the 'task' packages: You "apt-get install task-gnome-desktop", and it installs a whole bunch of reasonable defaults.

(The "task" packages are content-free-- they consist only of dependencies on other packages).

Re:Automaticness

[IamTheRealMike]

Yeah, but you're forgetting about the disadvantages of NeXT style .app files (well, actually directories). It's basically just like the old DOS days, when apps were entirely self contained. Some quick problems with this system:

• Very little code sharing. The reason we're having this discussion is because in general Linux apps share a lot of code, and because Linux is developing very rapidly right now you often need different versions of it. How do I say, "this program requires KDE3, and won't work with 2" when I have a completely self contained program?
• No install time scripting/configuration. Yes, I know there are some people who think this is evil, but often for more complex apps it is necessary.
• The OS is not notified when new software is present. There are all sorts of uses for this feature, such as dynamic menu creation etc

Basically, the OSX/NeXT .app method wins hands down for simplicity, but it has significant architectural flaws. I'd rather we resolved the packaging system problems.

Re:Automaticness

[simm_s]

So you would rather replace dll hell with search for the correct package hell? Versioning is something that you cannot avoid in a complicated system. A legacy program that links to libx-1.0.so may not work with libx-3.0.so. Thus you may have to have both libx version 1 and 3 and a general link libx.so linking to the higher version.I do not know what you are talking about versioning is not impossible.

Also UNIX has static linking and is not immune to a DLL hell like syndrome.Though I am a devoted follower of the Slackware distro, Windows has something going for it. I grab a zip package run setup and the program is ready to run. Why can't we have the same in Linux?

Re:Automaticness

[simm_s]

Problem is that Apt Get only works on Debian and its derivatives. I have no problem using slackware 8 and packages that are designed for slackware 8.

It is when I am developing a 50MB program on slackware 8 and I need it to work in Redhat, SuSE, Debian, Gentoo, etc when I have a problem. I love apt-get and the freebsd ports collection but that does nothing for me in my slackware distro.

Re:Automaticness

[Aapje]

Only the newest most up to date library should need to be on the system. If the libraries aren't backwards compatible or software isn't forwards compatible that is another design flaw

Nonsense. Do you know what a depreciated API call is? Versioning allows for old applications to keep working, while apps that are compiled with the new library have to use the new calls (or you can't use the new library with all of it's cool features)*. This is the only way to avoid the curse of ever expanding API's aka code bloat. The result is cleaner applications and libraries that can be improved much easier (and are smaller).

And please don't argue that depreciated API calls are bad engineering. Some developers aren't clairvoyant and/or perfect and don't know what features will be needed tomorrow or the absolute best approach for a particular problem. Even the best of them will create imperfect API's.

* The best system would probably have a depreciated-warning for the first few major releases after something is depreciated. That allows you to incrementally remove warnings. But ultimately they have to be removed. The longer you wait, the greater the diversity will be between different apps calling your library. This will turn into a maintainance nightmare.

Problem not entirely RPM's fault

[Arethan]

RPM by itself isn't the real problem here. The author is complaining that installing applications in Linux is a pain in the ass, because the system often doesn't have all of the required libs installed.

I admit, RPM doesn't make this an easy problem to solve. Any normal Windows app would simply package the required libraries with it. Thus if the lib doesn't exist, it can install it. But RPM doesn't work that way. RPMs can only hold one logical unit. So one app, or one library, or one set of platform independent support files. RPM builders could include more, but doing so will likely break the RPM dependancy tree.

The real problem in all of this is the destinction between applications and the system itself. Is grep part of the OS, or is it an addon app? How do you tell? Most would argue that grep is a part of the OS, but you can easily install linux without grep, so it must not be essential. But if packages expect it to be there, then it must be essential. But if it's not part of the OS, then they shouldn't have expected it to be there in the first place, so now it is their fault for not thinking ahead... This problem just goes in circles all day. The worst part about this is that my use of grep is just an example. This problem applies to literally all packages outside of the kernel itself. Don't believe me? How about init? Do you think that init is essential? I agree, but what version? Do you want a SysV init, or a BSD style init? Technically you can have either.

To solve this whole problem, we really need to take two steps. First we need to define a base Linux system. And I don't mean a completely solid, unwavering, definition either. Standards that never evolve are quickly dubbed 'legacy'. The trick is to define a complete base install. Everything from the kernel, to the version of GCC (and no RedHat, gcc 2.96 isn't going to cut it), to what version of X is installed, to what "expected unix utilities" are available, and what libraries are available. Feel free to change the standard, but each time you do so you must raise the bar somehow, either by making it more reliable, or faster, or adding features, or some combination of the above. There is only one last key item to making this system work. You must retain backwards binary compatability for long periods of time. Feel free to completely break legacy systems, but make sure that you only do so after you've had at least 5 to 6 years of stability.

Then there is the second step. RPM is a nice system management system, but it is a shitty application packager. Mostly because of the dependancy issues and the fact that each RPM package can only hold one logical unit. We really need an install shield like system for applications (both gui and console installs in the same package). Feel free to keep track of what is installed, and what files belong to who, but you really need to separate the system from the applications. Once you have a base defined, keeping the system and apps under the same packaging system no longer makes sense. The absolute need for it is removed.

Re:Problem not entirely RPM's fault

[Apreche]

Damn Straight! I used all my mod points yesterday, and I already posted a comment below anyway. But at least someone out there besides me thinks InstallShield is a good idea. You rock.

Re:Problem not entirely RPM's fault

[GigsVT]

Have you ever heard of POSIX?

Re:Problem not entirely RPM's fault

[Arethan]

Neither of which are complete enough to allow for binary compatability, and don't even touch on file system layout.

The problem with ANY packaging system....

[wowbagger]

The problem with ANY packaging system is overzelous dependancy definitions.

When Maynard builds his SuperFlyFloobyDust.rpm file, rather than specifying the dependancies as "I need libPease.so", he accepts the default "I need libPease.1.4.2.thursday.5-31-41.1-pl3-build6.so". So, even though any libPease.so would work, you get a dependancy failure.

This is a failing not of any specific package manager - ALL package managers have this problem. You don't see it with .debs not because of any inherent superiority of .deb, but rather because of the hard work of the Debian maintainers to make sure the packages are all set up correctly!

Additionally, there is the problem of library makers not following the fscking standards - libNarf.1.1.so is SUPPOSED to be fully compatible with libNarf.1.0.so - if it isn't, then it should be libNarf.2.0.so! However, you get people making libraries that don't follow this rule, so as a result you have to have libNarf.1.[0-99].so in your system because of programs that depend upon their version of that library.

The solution to this CANNOT reside within the package manager - it resides in the distribution maintainer to refuse to deal with packages that break the rules.

However, all it takes is one person installing one program that breaks the rules, and that installation is screwed.

That is where distros like Debian and the *BSD's have the advantage - they are controlled by folks who won't let that happen. However, how many people install from the unstable branches, and why? Because that's where the latest, greatest, shiniest stuff is!

Re:The problem with ANY packaging system....

[spacehunt]

When Maynard builds his SuperFlyFloobyDust.rpm file, rather than specifying the dependancies as "I need libPease.so", he accepts the default "I need libPease.1.4.2.thursday.5-31-41.1-pl3-build6.so". So, even though any libPease.so would work, you get a dependancy failure.

This is a failing not of any specific package manager - ALL package managers have this problem. You don't see it with .debs not because of any inherent superiority of .deb, but rather because of the hard work of the Debian maintainers to make sure the packages are all set up correctly!

Actually .deb does not allow file dependencies -- only package dependencies are allowed. So if a package needs "libPease.so.1", it will Depends: libpease1, not on the actual library file.

File dependecies makes RPM-based systems so much more unmaintainable that, in fact, the LSB forbids them.

Re:The problem with ANY packaging system....

[wowbagger]

You misunderstood my statement - the same problem can happen with a package dependancy.

Suppose that Maynard has package libPease.1.4.2.thursday.5-31-41.1-pl3-build6 installed, which is supposed to be back-compatible to package libPease1. When he builds his .debs, he mistakenly builds it with a dependance upon libPease.1.4.2.thursday.5-31-41.1-pl3-build6, rather than libPease1.

Same problem. Only if your packaging system does not allow subversions of a package can you avoid this problem. And if your package does not allow subversions, then if I really do need a feature of libPease.1.4 or later I am screwed - I cannot spell that out in the packaging system, so somebody will install my package when they only have libPease.1.0. Then I have to tell them at runtime they don't have the correct package.

A partial solution would be for every package to supply a list of packages it is backward compatible with, and for the installer to check that list when installing a package. Then, when you install SuperFlyFloobyDust, the install can say "OK, libPease.1.5, can you take the place of libPease.1.4.2.thursday.5-31-41.1-pl3-build6?", and libPease.1.5 would have to be able to answer that question.

This is not a full solution, however - libPease.1.4.2.thursday.5-31-41.1-pl3-build6 could be some bastard version that has a functionality that was not incorporated into libPease.1.5, and libPease.1.5 might not ever have HEARD of it.

Additionally, SuperFlyFloobyDust might NOT really NEED the functions of the bastard version, and so even if libPease.1.5 could correctly state "No, I am not a total replacement for that bastard version", SuperFlyFloobyDust could actually run on libPease.1.5, but due to being packaged by an incompetent boob, the program won't install.

File or package dependancies are the same. Unless you forbid sub-versions, you have this problem. And if you forbid sub-versions, you introduce other problems.

Re:The problem with ANY packaging system....

[spacehunt]

(Perhaps I should point this out earlier: I'm a Debian Developer, so consider myself biased.)

Yes, .deb alone can't solve this problem; but in cases like these the Debian Policy has some guidelines.

Suppose that Maynard has package libPease.1.4.2.thursday.5-31-41.1-pl3-build6 installed, which is supposed to be back-compatible to package libPease1. When he builds his .debs, he mistakenly builds it with a dependance upon libPease.1.4.2.thursday.5-31-41.1-pl3-build6, rather than libPease1.

In this case, "libPease.so.1.4.2.thursday.5-31-41.1-pl3-build6" should be in the package "libpease1", version "1.4.2.thursday.5-31-41.1-pl3-build6". Other packages always do a Depends: libpease1.

The reason that the major soname is in the package name itself is because, binary API changes are supposed to happen when the major soname changes. This way, there might be a "libPease.so.1.xxx" and a "libPease.so.2.xxx" that are binary incompatible but can coexist together on a system; and so there will be "libpease1" and "libpease2" packages that can be installed together; but "libpease1" version 1.5 will replace "libpease1" version 1.4.2 during upgrade, because upstream says they're binary compatible.

Same problem. Only if your packaging system does not allow subversions of a package can you avoid this problem. And if your package does not allow subversions, then if I really do need a feature of libPease.1.4 or later I am screwed - I cannot spell that out in the packaging system, so somebody will install my package when they only have libPease.1.0. Then I have to tell them at runtime they don't have the correct package.

As long as the binary API remains backwards compatible, then the "libpease1" package can be upgraded to 1.4, and packages that require 1.4 features can Depends: libpease1 (>= 1.4). If libPease.so.1.4 is not binary compatible with libPease.so.1.0, then it really should be called libPease.so.2.0. If it isn't, then upstream has stuffed up, so nag upstream about it (I've done it before).

Additionally, SuperFlyFloobyDust might NOT really NEED the functions of the bastard version, and so even if libPease.1.5 could correctly state "No, I am not a total replacement for that bastard version", SuperFlyFloobyDust could actually run on libPease.1.5, but due to being packaged by an incompetent boob, the program won't install.

This is the problem of the person who did the package, yes? She should test the package before releasing it to the world, just like any other software, whether in source code or binary form (especially in binary form).

No system can guard against incompetent packagers. But with RPM's file dependencies, it's much, much easier to make a mess.

Re:The problem with ANY packaging system....

[wowbagger]

And this is my point exactly - the problem is people screwing up and making binary incompatible package versions - asserting that libPease1, version 1.5 is a full and complete replacement for libPease1, version 1.4 when in fact it isn't. And no packaging manager software can fix that - it is incompetence on the part of the package creator.

That is the point I keep trying to make - .debs are superior to .rpms because of the work of Debian maintainers who bash morons who cannot understand that same major version MUST MEAN binary compatible.

Unless we start vet'ing packages for compliance with that simple idea, no package manager created can solve the problem.

Now, I will agree RPM has its warts - I agree that being able to depend upon a FILE, rather than a PACKAGE is a weakness. However, until we get an agreed-upon standard that a given file will ALWAYS be supplied by a given PACKAGE, this is an unavoidable problem - I've seen the same file supplied by completely different packages (e.g. the RPMs supplied by Abiword and the abiword packaged supplied by Ximian).

How would you create a .deb if you needed /usr/bin/foo and it could be supplied by Foo.deb or FooAndNarf.deb? Which package would you tie to?

Again, the solution here lies not within the package system, but rather the package creators - until you get a means to guarantee that package maintainers are "following the rules" you will have these problems, be you Debian, RedHat, or Microsoft.

Perhaps what we need is for a consortium of distro vendors to create a mark of trust. A would-be package creator can sign his packages with a key, and ask to register that key with the Package Police. If the package creator proves he can package something CORRECTLY, his key is marked as trusted. If he starts screwing up, it gets marked as untrusted.

Perhaps we could even create a system by which end users could vote on a given package - positive trust points for good packages, negative trust points for badly packaged libraries. Of course, since there are always people who seek to screw such a system up, we would need people to review the votes those other people cast, and remove the people who abuse the system. Then we would be able to see whose packages were good, and whose were crap. Of course, there would always be the dicks who rushed to be the first to vote on a package....

Re:The problem with ANY packaging system....

[Sentry21]

When Maynard builds his SuperFlyFloobyDust.rpm file, rather than specifying the dependancies as "I need libPease.so", he accepts the default "I need libPease.1.4.2.thursday.5-31-41.1-pl3-build6.so". So, even though any libPease.so would work, you get a dependancy failure.

This is a failing not of any specific package manager - ALL package managers have this problem. You don't see it with .debs not because of any inherent superiority of .deb, but rather because of the hard work of the Debian maintainers to make sure the packages are all set up correctly!

Incorrect. RPM depends on files (/usr/bin/perl) and libraries (libPease.1.4.2.thursday.5-31-41.1-pl3-build6.so). Debian relies on packages (perl, libpease >= 1.4.2). This provides a lot more flexibility, in that you can replace packages with other packages, 'provide', and not require any one filename. Services can be required ('httpd') without specifying anything specific (/usr/sbin/httpd, /usr/sbin/roxen2), and packages that provide what is needed can provide that virtual package name.

However, all it takes is one person installing one program that breaks the rules, and that installation is screwed.

There have to be some pretty big changes to screw up a Debian installation, in my experience. I ran Unstable, doing updates twice a day for three years, and never had to reinstall. The worst thing I had to deal with was the glibc upgrade, when I lost apache for a few days until it was recompiled. The Unstable branch still has quality guidelines (Debian packaging policy), but it's fast and loose. If you want cutting-edge and safe, go for testing, which has any packages that were in unstable for 2 weeks without having big bugs filed against them.

--Dan

Re:The problem with ANY packaging system....

[wowbagger]

Sorry, but you are wrong - RPM depends primarily on packages. File dependancies, while possible, are rare.

I suggest you go over to rpmfind.net and look at the listings on several random RPMs. You will see that in most cases, the RPMs depend upon other packages - rarely do they depend upon specific files.

And by "screw things up" I don't mean "cause the system to become unusable", I mean "cause invalid dependancies that make installing packages needlessly difficult". As I had said in several previous messages, that does not happen, even on Debian unstable, more due to the work of the Debian maintainers than to any inherent superiority of .deb over .rpm.

I suggest a browseable, book-like interface.

[Futurepower(R)]

Having 50 (only that many) different styles of configuration files definitely makes things tough. However, the information is not hidden from the user, as it is in Windows.

It would be great if someone standardized Linux configuration files. I suggest a browseable, book-like or PDF-like interface like that in Ganymede. Each package would be expected to write their own interface to the configurator. That way, authors could have any configuration file format they wanted, but there would also be a standard GUI interface.

Re:I suggest a browseable, book-like interface.

[mark_lybarger]

XML as noted is merely a vehicle for storing data. the biggest gain is in its accompanying technologies. XSL/XSLT, DTD, schema's, can be used to provide usefull interfaces so the end users never has to look at or decipher an xml file.

Hated RPM issues

[JamesGreenhalgh]

rpm -i

Sorry, you need libpng x.y.z_e, but you have libpng x.y.z_c.

Above is not of course technically accurate, but many MANY times I end up annoyed with RPMs since theyre put in a requirement for a SPECIFIC named package and version (on the builders system) version of something. You can end up needlessly having to upgrade libraries when you already had an entirely adequate version for the package in question.

Solaris package management works. It can't really help us here though, since Solaris installations are generally very generic things - linux machines can be any one of thousands of combinations of package versions. Back to linux-land, and apt-get with debian mostly works, but a few times I've seen a debian machine decide to upgrade more or less the entire base dist for a trivial tool due to versions, and break in the process while replacing libc. Not fun.

The only workable solution I've seen thus far, is the freebsd ports system. Grabs the generic source and builds it in such a way that it only upgrades backup tools and libraries when it really needs to. I've NEVER had a serious issue in years of using this system. That's not to say it's perfect of course, still suffers the issue of you not being able to easily revert to your old setup if an installation breaks somethings, and of course it can be pretty slow.

Something does need to be done though. A Windows using friend of mine tried to install Mandrake recently, which he did all on his own without issues. He wanted an IRC client, I recommended x-chat. We tried using RPM and it failed, so we grabbed the source and then had to go about installing a set of development tools on his machine. It took a *long* time before the gcc package would install due to some idiot deciding headers should be split from main packages for the sake of a few kb of diskspace. Even then x-chat wouldnt build, due to things like the gettext rpm not having msgfmt (part of gettext), someone having decided it lived in an openwin tools rpm, which would no doubt have wanted lots of openwin rubbish installing. Eventually we ended up splatting source versions of common tools on top of the rpm installed ones to resolve several instances of missing header files and scripts. Finally, x-chat built...

It made *my* head hurt let alone his - and I've been working with *nix machines for years. It almost put him off trying to use linux any further straight away. Linux is never going to start making any non-techie inroads unless someone sorts out a decent packaging system, and fast.

Re:Hated RPM issues

[mickwd]

I'm really surprised about your problems. I run Mandrake, on several machines, and I've installed XChat on each of them (on various different releases - 7.1 upwards) without any problems.

Try 'urpmi xchat'. It'll take care of dependencies for you, telling you what else your need to install, and trying to do it for you. I don't normally use it - RPM on it's own is usually sufficient for me.

I've also built XChat from source without any problems. (Why? Because the RPM packages are often built without python support, which I use). Again, no problems.

You say you've had problems because of dependencies on other libraries. Well, if XChat depends on those libraries, you'll need to have them on your system whatever package management (or other) system it's build with.

If your RPM database gets screwed up, use the following command to rebuild the RPM database:

rpm --rebuilddb

.deb

[Simon Brooke]

I started my Linux experience with SLS and a 0.99 kernel. Then I switched to Slackware, then flirted with Caldera. Then for a while I ran RedHat on my servers, before switching in about 1999 to Mandrake on all machines.

And then I decided to experiment with Debian on a test box, and fell in love. I now have it on my desktop, my laptop, and three out of my five servers.

Why?

The package manager. It just works. It just works reliably, installing all the right stuff, resolving all the dependencies. When there are conflicts (not often) it reports them and suggests remedies. In short, the Debian package manager is to all other UN*X package systems I've ever seen as a computer is to a tally-stick. No-one who has used dselect will ever go back to RPM.

Re:.deb

[gik]

Thank you, sir, for your whole personal experience with linux.

I, and all those around me are truly appreciative that we now have a glimpse of your entire linux distro history.

Re:.deb

[PSC]

No-one who has used dselect will ever go back to RPM.

That would be because they can't figure out how to quit the damn thing!

Re:.deb

[MSG]

No-one who has used dselect will ever go back to RPM.

Actually, dselect has been known to drive users the hell away from Debian. Its interface is rotten, and the authors agree. It's unfortunate, since dselect and apt really do good things. It just takes a bit of adjustment to get used to dselect.

I was considering moving over to Debian myself before apt became available for rpm. I'm much less motivated now ; )

Re:.deb

[reflective recursion]

Heh. I tried Debian pre-apt, and I remember dselect. I had Debian about 2 days before Slackware went back on. Even Red Hat lasted about a month (a terrible month, at that).

I think the reason people (or at least I) use Slackware is they realize the futility of managing packages and dependencies. They understand that once a package is installed, it is more-or-less a permanent fixture in their system. No promises or false guarantees. Want something removed? You gotta get your hands dirty.

Of course, package management has become someone nicer today..

The problem with this article

[phaze3000]

This article really shows more about the author's experience than it does about the merits of any particular package management system.

Let us for a moment pretend that instead of using .debs (but still had APT, ala Connectiva), Debian used RPM for its package management. Would Debian be as good as it is now? Of course. Why is this? Well, because the Debian people spend a hell of a lot of time making sure the package management is done properly. This has drawbacks of course, like the lack of the latest-and-greatest software (notably XFree86 4.2 and KDE 3), but in terms of stability you really can't argue that Debian is the best around.

The author then goes on to suggest that a Gentoo-like system is whats best. Quite frankly this just shows us more about how little the author understands what is necessary in a package management system. Don't get me wrong, I like Gentoo a lot (in fact I type this message on a machine running Gentoo :)) but package management really isn't its strong point, as things like the recent libpng problems show. Doing things this way makes dependencies extremely difficult to deal with. Lets pretend you have libxyz installed, and then install program abc. abc can use libxyz, but doesn't require it. As you have libxyz installed, gentoo compiles abc with libxyz support enabled (one of Gentoo's best features). However, the day after, you decide to 'emerge unmerge libxyz' (remove libxyz for Gentoo virigins). abc no longer works properly. Gentoo didn't tell you that abc needed libxyz, because it's not a dependecy.

In my opinion, the package format is irrelevant; RPM, DEB, TGZ, all are fine as long as they are centrally controlled and well put together. A system like APT makes things many, many times better, becuase it eases dependency problems, but it isn't a pre-requisite.

Speaking of compiling...

[mikeboone]

I've found it easy enough to compile from source when there's no RPM or I need to set lots of parameters (i.e., PHP).

But what about uninstalling? Is there a command I'm unaware of to remove software compiled and installed from source? It's easy with RPM.

Re:Speaking of compiling...

[HiThere]

Most of the makefiles I've looked at don't have an uninstall. clean, however, they do tend to have. And frequently distclean.

Also, with rpms if there are dependency problems you tend to not get an install. With tarballs, the make will fail at some point, and if you are lucky it will be before any actual installation has occured. But you sure can't count on it!

Why are you blaming RPM?

[Spazzz]

Ladies and gentlemen, I hate to be the one to inform you, but this isn't RPM's fault, this is the individual distro vendors' faults for not standardizing on a filesystem hierarchy.

I also blame the users who don't have enough sense to build thier own rpms. It's not *that* hard, if you have a SRPM, to build an RPM that works on your system where the binary may have failed. In fact, I recommend that if you use RPMs that don't come from your distribution vendor, you get the source RPM, edit the spec file as appropriate, and build your own...this way you're linking against *your* version of whatever libraries you have installed. It's not *that* hard, trust me.

-Jeff

Luke, package the damned source

[Nailer]

Really, there is nothing to difficult about:
./configure
make
make install

And all RPM does is automate and standardize this process. The strength of any management system is based around its ubiquity. Installing software outside the packaging system is a bad idea, as suddenly all those standard installation, uninstallation, querying, and verifying systems no longer work - for your unpackages apps, and all the broken packages or other unpackaged apps that rely upon it. Stop thinking of RPM as being seperate from source. it isn't. An RPM is a cpio archive with a source tarball and a spec file like the one below which automates the build process.

Summary: An addictive and frantically paced puzzle game with cute 3D graphics
Name: crack-attack
Version: 1.1.7
Release: 2mm
Source0: http://aluminumangel.org/cgi-bin/download_counter. cgi?attack_linux+attack/%{name}-%{version}.tar.gz
License: GPL
Group: Amusements/Games
URL: http://qcd2.mps.ohio-state.edu/attack/
Packager: Mike MacCana
BuildRoot: %{_builddir}/%{name}-%{version}
BuildRequires: glut-devel
Requires: glut
%description
Crack-attack is addictive and frantically paced puzzle game with cute 3D graphics, playable either against the computer in single player or across a network mnultiplayer, where o
ne players success clearing blocks dumps large immuntable tiles upon the others block pit. Muahahahaha!
%prep
%setup -q

%build
%configure
make

%install
%makeinstall

%post -p /sbin/ldconfig

%postun -p /sbin/ldconfig

%clean
rm -rf %{buildroot}

%files
%defattr(-,root,root)
/usr

This will catch all the files installed in /usr, but after you do this, note the names of these files in the package and specify them individually

%doc AUTHORS COPYING INSTALL NEWS README

%changelog
* Thu Apr 11 2002 Mike MacCana 1mm
- Created packages

Now I'm going to sit back down on my Red Hat 7.3 box and apt-get dist-upgrade all my RPMs from Freshrpms.net

What about BSD?

[demaria]

The BSD ports and packages work pretty well.

cd /usr/ports/comm/kermit
make
It downloads, compiles, and installs.

Got a package file? add_pkg package. The article didn't make any mention of these possibilities.

Re:What about BSD?

[demaria]

I know that. But why can't Linux use or consider BSD style ports & packages?

This is why I hate RPMs!

[farrellj]

When I download a source tarball, I can look in the README or INSTALL file, and find out what things it needs. RPMs have no such facility. Add to that, who *knows* what command line options were used, if some features were left out, etc.

I'll stick with source, thank you.

ttyl
Farrell

Re:Talk about a gimmick

[EricLivingston]

You're so wrong. I've switched to Gentoo and won't go back to binary distribution, ever. Compiling from source allows you to, for instance, automatically compile anything that can use LDAP, for instance, with that support (or not, if you don't want it). Similarly, support for SSL, Kerberos, postgresql, etc, and many, many other optional "features" can be universally turned on and off in everything you compile. I've found it extremely annoying in the past to install an RPM only to find that the rpm maintainer didn't select compilation options that I need, so I'd wind up having to recompile anyway. Now I know that every single package on my system is compiled with exactly the options and library support I want. Not to mention my entire system (glibc, KDE, kernel, etc) is compiled with -O3 -march=i686 (etc) which has noticably sped up my system.

Re:Gentoo is a giant step, too long for mere morta

[0x0d0a]

You do realize that you can do a minimal installation of RH and install as you see fit? Just like Debian? The main difference is that you actually have industrywide support for your distro.

Not really...

[bero-rh]

While the article raises a couple of valid points (such as the crazy incompatibilities between some versions of rpm, a lack of standard package file names and standard locations), its conclusions are wrong.

Let's see:

1. An RPM-based distribution is risky to upgrade

Not quite. Red Hat, for example, still supports upgrading from Red Hat Linux 4.x to current versions, if you use the official updating process.
You can run into problems if you upgraded some stuff by yourself, which is true for any package manager. A good package manager doesn't downgrade packages during an upgrade process. How is it supposed to handle an "upgrade" from a custom kdebase 3.0.1 installation (compiled with libc 5.x) to the kdebase 3.0.0 package found in the distribution you're trying to update to?
Downgrade things in the process? I think that would make people complain, as well.

Similarily, apt-get works quite nicely for Conectiva users.

2. A more complex binary RPM package is often hard, if not impossible, to install

Again, this is not exactly specific to RPM. The problem here is that RPM is used much more widely than any other package manager, therefore RPM packages are typically built on a wider range of potentionally VERY different systems than other packages.
If, say, 200 distributions used .deb, you'd run into just the same problem here - your system uses, say, glibc 2.2 and libstdc++ from gcc 2.95.4 while the package you've downloaded was built with glibc 2.3 and libstdc++ from gcc 3.1. No difference at all.

3. The incompatibilities between different versions of the RPM Package Manager added another layer of complexity.

This is true, and the only real rpm specific problem.
There's always a tradeoff between new features and backwards compatibility, and rpm does seem to lean a bit too much towards new features.

4. The developers are forced to consider differences between distributions and create multiple binary packages.

This is just restating point 2, and is just as invalid.

Same for the suggested "solutions":

1. Learn to build your own RPMs

This actually does fix some problems... But of course you can't expect everyone to do it.
(See also #5)

2. Petition the RPM distributions to adhere to common standards.

Nice in theory, but because there's no real standard ATM, this would mean breaking compatibility with older versions of the distributions (by e.g. adapting a common scheme for naming packages so you won't need to make a difference between Red Hat'ish "Requires: kdelibs >= 3.0.0" and Mandrake'ish "Requires: kdelibs3"), possibly breaking the update path.

3. Use more advanced package management tools, such as urpmi or apt-rpm

I agree with this one (add up2date to the list, btw). The availability of those tools shows that rpm is actually a good and flexible package manager - it just needs some extra tools to simplify some common tasks. It's really the Unix way of doing things - have the tool do one job, and have it doing that one job (handling individual packages without resolving dependencies by itself, in the case of rpm) well. Then write other tools making use of the tool (rpm) to get more advanced functionality.

4. Switch to Debian or Slackware

As shown above, their package managers do not solve the problems mentioned in the article. The problems just happen not to show up so frequently because there aren't many distributions using these package management systems, and the ones that do are usually pretty close to the distribution they're based on. Much closer than completely different distributions like e.g. Red Hat and SuSE, which really don't have much in common except for the package manager.

If, say, Red Hat switched to using .debs, you'd immediately run into the problem that, due to totally different base systems, Red Hat .debs wouldn't run on Debian without changes and vice versa.

So this switch wouldn't gain anything.

5. Switch to source-based Linux distributions, such as Gentoo or Sorcerer

This does solve the problem, but introduces others. It's a good thing for some people, but certainly isn't a universal solution to all problems.

Source based distributions are really nice for people who want to tweak things a lot, but they aren't very useful for a traditional desktop user (who typically doesn't have all that much of a clue and doesn't want to spend a lot of time learning), and they introduce problems even for users who can handle them.

Let's assume you have a source based package manager that is dumbed down enough to allow a user to install a package by clicking on a package file in Konqueror or Nautilus.

Here's some of the problems you'd still need to solve (and some of them really aren't fixable):

• The user needs to have all development tools installed - including, depending on what packages they want to install, compilers for very obscure languages (how many of us have installed compilers for, say, Modula 3 and Objective-CAML?)
• Installation takes forever. This is not a problem for small packages, but how do you explain to Joe User that, after clicking "Install KDE 3.0", he can't use his new KDE 3.0 for a couple of hours?
  This is a real problem on slower machines - Compiling, for example, OpenOffice takes approximately 13 hours on an Athlon 1800 with 1.5 GB RAM. Imagine installing it from source on a Pentium with 128 MB RAM...)
• How do you handle binary-only stuff? In an ideal world, of course, you don't use any. But try explaining to Joe User why he can't see websites using Flash... I'm all for banning binary-only software, while it's there it needs to be handled.
• No beginner-friendly error messages. How do you explain a newbie what
  foo.cc:123: invalid conversion from `const void*' to `void*' is supposed to mean? (It's typically an indication of broken code that happened to work with gcc 2.x, but doesn't work with gcc 3.x anymore - but how does a newbie know or fix it?)
  

Besides, rpm is powerful enough to provide this functionality for people who want it, combining the best of both worlds - it's typically as easy as


rpm --rebuild foo-1.0-1.src.rpm
rpm -ivh /usr/src/redhat/RPMS/i386/foo-1.0-1.i386.rpm


This still has the same problems as a pure source based distribution, but with rpm, you get the choice between building from source and installing the binary.

It's the primary reasons why I prefer rpms over debs, by the way - they're much easier to build.

Re:Not really...

[teamonkey]

4. Switch to Debian or Slackware

As shown above, their package managers do not solve the problems mentioned in the article. The problems just happen not to show up so frequently because there aren't many distributions using these package management systems, and the ones that do are usually pretty close to the distribution they're based on. Much closer than completely different distributions like e.g. Red Hat and SuSE, which really don't have much in common except for the package manager.

If, say, Red Hat switched to using .debs, you'd immediately run into the problem that, due to totally different base systems, Red Hat .debs wouldn't run on Debian without changes and vice versa.

This is surely due to the various distributions not conforming to the LSB and FHS, rather than the shortcomings of the package management system? Debian is far more standards-complient than RedHat, and Slackware is even better.

With the version of apt that comes with woody, you can choose from which version you wish to install the debs from.

For example, you can track woody for the most part, but if you want the occasional package from sid you can do that too, and it will work out the dependencies automagically. The same would be true for multiple distros - just give it a different name and add the entries to your sources.list file.

My current system was originally Progeny Linux, which was then merged with woody, then sid. Using apt, I had no problems moving between systems.

Sure there were some incompatibilities between the packages, but the deb format is robust enough to at least identify the problems (and in some cases offer a solution). This, I believe, is where RPM falls down.

--teamonkey

Re:Not really...

[Wdomburg]

>This is surely due to the various distributions >not conforming to the LSB and FHS, rather than the >shortcomings of the package management system? >Debian is far more standards-complient than >RedHat, and Slackware is even better.

Sorry, but Red Hat's lack of complaince (or lack of willingness to comply) with the LSB is a myth.
These aren't the official results, but preliminary test results at freestandards.org show Red Hat as passing more tests than Debian, SuSE, and Caldera.

Among some of the issues that Debian were that their init scripts didn't provide a status command, and that there was no distinction in runlevels 2-5. I haven't kept up with development too closely, but my Debian installation, which has been apt-get upgraded fairly recently still has these issues.

As for Slack, last word from Patrick Volkerding that I know of is that he's taking a "wait and see" approach; i.e. he's not even bothering to strive for LSB complaince until he's convinced that compatibility is improved between compliant distributions, although to his benefit he said "I'm sure this is a step in the right direction."

I haven't used 8.1 at all, but Slackware probably has the most work cut out for it if they decide to try to move towards LSB compliance - their init levels are non-standard, their init scripts are completely non-standard (kind of a weird hybrid BSD/SysV approach), they fail a good potion of the FHS tests, etc, etc.

In other words, nit picking aside, Red Hat and Deibain are pretty much on par as far as comformance go, and Slackware is way off.

Matt

Re:Not really...

[swillden]

rpm --rebuild foo-1.0-1.src.rpm
rpm -ivh /usr/src/redhat/RPMS/i386/foo-1.0-1.i386.rpm

It's the primary reasons why I prefer rpms over debs, by the way - they're much easier to build.

How is that easier than:

apt-get source -b foo
dpkg -i foo-1.0-1_i386.deb

Seems the same to me.

Re:Why RPM's?

[0x0d0a]

You do realize that you can extract the source from srpm files easily and build however you so desire?

There are lots of tools that can do it. If you happen to have rpm on your system, rpm -Uvh on the src.rpm will dump the tarball off in /usr/src/redhat/SOURCES on a RH box, for example.

Re:RPM is a POS

[0x0d0a]

A simple packaging system based on tarballs, a la Slackware

Try administering a network.

My experience with Slackware is seeing people managing to *just* get their system working and then leaving chunks of the software along and letting it get ancient because they don't want to break anything. They upgrade a library, they end up with zillions of broken library dependencies and programs that won't run.

RPM can do most of what this crowd wants...

[psychosis]

I was very anti-RPM a few years back - even as late as RH7.0. I still compiled all software from .tar.gz source and installed appropriately. If I couldn't get the source to compile for some reason (strange dependencies that I could not track down), I'd end up trying a rpm -Uvh --nodeps foo.i386.rpm. Without the --nodeps, the installation would fail 99% of the time - the files it needed were there, but not in the RPM database.
Then, for some reason that escapes me now, I tried a pure rpm-only box. Dependencies were still a pain the the ass to some extent, but much easier with sites like rpmfind - just type in the missing dependency and d/l the topmost result for your architecture, and voila - the original package installs fine.
I missed being able to compile from source, though. The security aspect is one major plus, but being able to tweak PHP to include EXIF, TrueType, and libGD support so my web apps keep working was the clincher.
Enter rpm -bb --clean /usr/src/redhat/SPECS/foo.spec. All you have to do is d/l the .src.rpm file, install it (usually installs 2 files /usr/src/redhat/[SPECS/foo.spec | SOURCES/foo.tar.gz]). You can tweak the .spec file (the ./configure line is in there - modify to your hearts content!), then do the -bb command listed above.
Grab a coke, come back, new package file specific to your installation is in /usr/src/redhat/RPMS/i386/foo.i386.rpm. Have a lot of like-OS machines (I have 7 RH7.3 machines at home)? Compile your binary RPM on the fastest machine (a dual P-III 850 VALinux box here), install the binaries on each machine.
This ability combined with the most EXCELLENT red-carpet and up2date capabilities in ximian and RH, respectively, make RPM usable for the masses. I have seen many low-end-tekkies (no disrespect, of course) using red-carpet on their personal machines with no hiccups. Need do remove something to get this new software? OK - it tells you. Need extra dependencies for the new package? OK - it's all automatic. (They don't even need to know that RPM and red-carpet are crypto-checking the stuff they install to ensure there's no man-in-the-middle work going on!)
RPM is really powerful. There's a LOT more than the features I've listed here. Want to see what files have changed since you installed the XFree86 RPMs? rpm -V XFree86. It tells you if the date, file size, contents (MD5 hash), and a bunch of other stuff have changed or if files are missing since install. It even tells you if the file is a configuration file, meaning a change in size, date, and content is not necessarily something to be concerned about.
Please don't think my support of RPM is blind - I have used Slack, played with Debian, and done the 100% source code route. RPM is a great tool, and most linux users (even some of the very skilled ones) don't use it to it's fullest potential. Spend a day or two reading the man page, the files in /usr/share/doc/rpm*, and make the call then.
Full disclosure - I am an RHCE, but I was sold on the advanced stuff RPM can do way before I took the class and test. Check it out - you might be surprised at what you've been missing. Feel free to e-mail me after unmangling the addy if you like...

Upgrading Mandrake & Debian packages

[Malc]

This article is rather coincidental to me as I posted something about upgrading Mandrake yesterday: Usenet post. I want to upgrade a Mandrake installation, but I don't want to 1) burn any CDs; 2) download MBs of data that I'm never going to use.

As for Debian packages, is it the package management applications that work, or the process (i.e. the hard-work, care and attention to detail of the people who create and manage the packages)?

Re:Upgrading Mandrake & Debian packages

[MBCook]

The reason that debian works is both. The package system and utilities (apt-get, etc) work great and have been designed great. But they could turn into the RPM problems if debian wasn't so strict. If you want your .deb file put into the offical repository, then it gets looked at and picked apart by many developers. So if you like your thing to install into /foo, they'll either change that or not take your package, because it should be in /usr/share/foo or /usr/local/foo or whatever it is (i'm not near a linux box right now and I can't remember, but it doesn't matter). I think a big part of it is the centralized controll.

Anyone can make a .deb file and put it on their website, but if you want it in the debian archive so people can 'apt-get install foo', then you have to make it comply.

On a side note, why not put debian on a box and try it out. That's how I started. I had a mandrake box and a second box that needed a reinstall, and so I tried debian and it won me over, quickly.

Re:Upgrading Mandrake & Debian packages

[Malc]

"On a side note, why not put debian on a box and try it out. That's how I started. I had a mandrake box and a second box that needed a reinstall, and so I tried debian and it won me over, quickly."

Actually, I have tried Debian. I'm running it on a headless server at home that hosts my personal domain. I really really like it. It's my experience with this machine that opened my eyes to what can be done, and been the catalyst for my aggravation when it comes to upgrading Mandrake. If I ever have to reinstall Mandrake, I'm just going to ditch it for Debian. I really don't need bleeding edge packages as I want to use my system now, not work around issues.

gnome, kde

[Ender Ryan]

While I am a bit miffed at gnome and kde for copying the registry idea(so friggin stupid.... imo), at least with gnome(not sure about kde, probably true there too) the "registry" is not one single massive database, it's composed of different hand editable text files, xml if I remember correctly.

Re:gnome, kde

[Znork]

Yeah, well, it can still 'break' massively. Try having nfs mounted home directories and poweroff a workstation without a shutdown... zzzzap, completely whacked gnome-conf. GConfd wont even run until you clear out its directory, and no error messages, and naturally no apps relying on gnome-conf will start without it.

Re:gnome, kde

[salmo]

Actually gconf doesn't care what the back end is. The standard one is based on XML files but you could use a database or an ldap server or just about anything you want that can store its key/value pairs.

Gconf is also great because its easy as hell to work on. Either tinkering with the files by hand or from the command line or using the ever nifty gconf-editor. The schemas are available to the user to check out so no configuration variable is completely undocumented although they do not explain what exactly they are used for.

People forget the biggest problem with the registry is not the registry itself its the number of undocumented keys that take difficult to comprehend values. Microsoft makes it difficult to understand on purpose under the guise of making it so "You have to know what you're doing to mess with it" which roughly translates to "Even if you work for Microsoft you shouldn't be messing with it. Bill knows whats best for you."

The registry-like idea is a natural decision. If you have a set of programs that use a similar text based config file format and they store all their config files in the same directory, thats registry-like. If you're building a DE, you're going to build a configuration API so that people can get and set values without having to reinvent the wheel every time. Gconf just makes it easy on programmers, users and sys admins.

We shouldn't be zealots that hate all things Microsoft just because they're Microsoft. If you find yourself needing something Microsoftish that you don't like, think about why you really don't like it and see how you can not fall into the same trap they did.

Re:gnome, kde

[IamTheRealMike]

KDE uses a series of .INI style text files for configuration - it's hardly the Windows registry.

Your article is flawed in a few spots

[erat]

1) Red Hat and Mandrake were/are not excluded from UnitedLinux. All Linux companies are welcome to join. They may not have been in on the initial UL chats, but had they been included I wouldn't be even slightly surprised if at least Red Hat would have caused the talks to go nowhere with their "we're the standard, be like us" mentality. Leaving the Red Hats of the world out of the round #1 discussions was probably the only way UL got as far as they did.

2) You oversimplify the issues of divergent Linux distros. If you think the main reason people leave distros like Mandrake is because of packaging issues, you're not looking at the big picture. I've tried just about all of the major Linux distros at any particular time (including SLS, TAMU, MCC, etc. from the days of the original Linux distros) and the only reason I have migrated from one to the other was because of operational issues and/or stability, not package management. The latter could have influenced my decision to move on, but it was never the majority reason.

3) You ignore the other direction people are going in (such as myself): *BSD. You toot your horn about Gentoo without acknowledging what Gentoo itself acknowledges: its package management system is based heavily on *BSD's "ports" system. Besides being sick of being told I can't use Linux unless I subscribe to the Linux religion, I find that the *BSDs (although not really compatible with each other) are simple to use, no more difficult to set up than your average mid-level-techie Linux distro, and I can get almost all of the same software running on it as I can on Linux. A simple "cd /usr/ports/[directory name]" then "make install" is all it takes. System updates? "cd /usr/src", then "make world" (assuming all sources are on the system, which is VERY easy to make happen).

Re:I don't think that's what he means.

[HiThere]

Say your package directory was /usr/app (or whatever, there are standards for these things, y'know) libpng would live in /usr/app/libpng, qt would live in /usr/app/qt. Things could still dynamically link them, and it would still Just Work. The only difference is that you don't have four hundred files all crammed in /usr/lib.

Almost. I think that he was really proposing that libpng version n.m would live in /usr/app/libpng/n.m . Which is only a refinement, but which is much safer. In the case of large packages this would cost a lot of disk space (how many versions of KDE or Gnome do you want to keep on your computer?), but OTOH it would be a lot safer. You could keep multiple versions of even so prevasive a package as KDE or Gnome during development, and if one didn't work, you could revert to an earlier version. (Yes, something like this is done during development anyway, but that requires special fiddling, and changing the directories around when it finalizes, etc. This approach wouldn't. And deleting an obsolete version would be nearly as easy as removing the directory (well, you *would* need to check for dependencies).

I guess that a side effect would be for the /usr/bin directory to become composed entirely(?) of links. Still, I've done that already when trying out a new version of Python, and it didn't seem to cause any problems. (I suppose that the other bin directories probably wouldn't be affected that way. Especially /bin and /sbin, since they might be needed when other partitions weren't mounted.

Re:Just got ADSL, Just had a nightmare with packag

[asv108]

An easy solution to avoid installing all those dependencies is to not install the dev packages unless you plan on actually writing kde apps which probably 99% of the people who install the dev packages don't want to.

Re:There is nothing wrong with RPMs. Only packager

[uhoreg]

The biggest problem I found with RedHat's packaging is that they don't do versioning properly. For example, I was trying to install GNOME a while back on an RH6.2 machine, and it needed [library] (I forget exactly which library it was) version x, but some other package on the system needed [library] version y. This meant that I couldn't install the prepackaged version of GNOME, and had to build it myself. This is just like DLL hell in Windows.

On the other hand, in Debian, if you have two versions of a library, and their API's are incompatible (which is the only reason packages would need to depend on a specific version of a library), you will have one package called, say, [library]1 and one package called [library]2, and packages can just depend on [library]1 instead of [library] version x. This way you can have both versions installed at the same time, and everyone's happy.

My second pet peeve with RPM is that you need to be root to build an RPM from source. In Debian, you just need to use "fakeroot", which means that the build process thinks you're root, but you can't accidentally do anything too nasty too your setup.

Re:cool

[0x0d0a]

If you're using any major Linux distribution, you're using a lot of software with development funded by RH.

All the major Linux vendors that I can think of fund general Linux development. Red Hat puts more money in than any other Linux distributor (at least partly due to virtue of sheer size, yes...).

This is why I get a kick out of people bashing distributors at the same time they're using software funded by them. "SuSE sucks, and they should die? Gee, I hope you don't like using X." "Red Hat sucks and should be wiped out by Debian? Gee, I hope you don't like using GNOME or gcc."

100% Irrelevant

[MoNsTeR]

Summary
1. An RPM-based distribution is risky to upgrade.

The author has a strange conception of how often "risky" distro upgrades are necessary. I've been using Turbolinux, and RPM distro, through versions 3.6, 4.x, 6.x, and 7.x. For each major revision, I've fresh-installed my box. But between major revisions, I can just d/l the rpms from the update directory and install them, no worries. Is the process for upgrading from RH X.1 to X.2 so different, so much more complicated?

2. A more complex binary RPM package is often hard, if not impossible to install.

The simple solution is, don't install 3rd-party binary RPMs. In fact, don't install 3rd-party binaries period, unless that's your only option. Any software that's too big of a pain to compile from source (like XFree) is going to be on your distro CD.

3. The incompatibilities between different versions of the RPM Package Manager added another layer of complexity.

Solved by above solution to #2. Half the problems the author has with RPM are caused entirely by the use of 3rd-party packages.

4. The developers are forced to consider differences between distributions and create multiple binary packages.

This depends on what kind of software we're talking about. If it's and end-user app, and the developers want new users to be able to install it, then yes, they probably have to work out multiple versions for each distro. But it seems they'd have to do that anyway what with different library versions and file locations in each distro. The fact that you can't issue a single binary tarball (term used generically) for all distros exists apart from any problems with RPM, it is a systematic problem with all distros.

The author also seems to think Debian is a magic bullet. I quit using Debian right as apt-get was being introduced. At that point, the distro swelled beyond a single CD, which at the time was a horrendous amount of crap to come in-the-box. I also didn't have broadband. However, though hard drives have sinced passed 100GB and I have cable, I still don't like the "Debian way". I'm one of those people that wants something physical, even if I'll only use it once. It's not a big deal to download new versions nightly and just archive the packages on disk, but if that disk goes then I'll have to get my entire distribution over again, instead of being able to install from physical media. But questions of update method aside, the author also ignores the horrendous problems with Debian package dependencies. Debian packages have, shall I say, comprehensive dependencies. That is, the .deb for any given app is going to depend on every library that app can conceivably be linked against, regardless of whether you intend to use that function. This is what led me to start compiling stuff from source. And what happens when you get an app that requirse a library version higher than what Debian currently offers? You either have to wait, or install that library from source yourself. Excep that breaks hundreds of dependencies! Joy! The Debian way is not for everyone, and Debian fanboys are seriously deluded as to the relative merit of their system.

The solution to RPM's shortcomings isn't to switch distros, or tack on apt4rpm etc, or anything as drastic as that. It is:
1. don't use 3rd-party RPM's.
2. upgrades...
a. if it's mission-critical, test it in a lab first, for pete's sake
b. if not, just do a fresh install, you learn something every time you do it

I'll also plug a little program I use, called pack. Pack is a replacment for /usr/bin/install, that logs the files installed when you run make install. It's extremely handy for managing the apps you install from source. Unfortunately development was discontinued some time ago, not that it lacked any features or had any bugs, but it may be unavailable.

HP axed calculator development a while ago

[0x0d0a]

They plan to keep selling existing models, but I think that RPN on the consumer calculator is going to go the way of the dinosaur.

Frankly, this move (and the others done to scrape together money, then merging with Compaq...WTF?) does a great job of showing that execs shouldn't recieve bonuses for closing mergers.

well, there ya go

[Ender Ryan]

Registry-like configuration is simply a very bad idea.

How bout a gconf-ish tool, that doesn't use a stupid daemon that can break, keeps all files in xml or similar in ~/etc, or ~/gnome or ~/kde.

I've had single crashes toast windows registries(not on MY machine, windows doesn't touch this thing), and a single crash(with a network home dir though, not *quite* as bad as windows) can break gconf.

When will people fucking wake up and stop trying to copy MS, but do it right. Many MS ideas are simply Very Bad ideas in the first place and there is simply no "doing it right".

The registry is the perfect example of this.

Ximian

[ajs]

Ximian's Red Carpet is left totally out of the discussion of package management over RPM. I use Ximian on top of Red Hat at work, and am very happy to never download an RPM for the OS or Ximian's add-on dekstop other than through Red Carpet.

Re:Is RPM Doomed?: Morons Please.....

[0x0d0a]

Particularly since the article basically claims that RPM is so popular that it's doomed.

Okay, there's a lot of fragmentation of the Windows API (CE, Win16, Win32 on NT, Win32 on 9x, the IE/Office extensions to each...), but I'm still waiting for Linux's World Domination, you know?

Why I keep going back to Debian

[teamonkey]

I've used SuSE, RedHat, Mandrake, Debian and a few others in the past. I keep thinking that a distribution has enough new features to warrent me changing, and then I hit the dependency problem and go back to Debian again.

This happened a few weeks ago when I installed SuSE on my old laptop because of its PCMCIA support. In the end I has so much trouble finding a RPM and its dependencies, I gave up and stuck woody on there. It took longer to set up, but I just need a net connection and apt.

I'm tempted to switch to Gentoo, but then there's always source DEBs, aren't there :)

apt isn't perfect though. Over a modem it takes a few minutes to apt-get update, and hours to apt-get upgrade, but it does make it so much easier! Also, Debian are very anal about their distro, even about unstable. There are still no (official) KDE3 or Openoffice.org debs (mainly because they don't work on all the supported platforms), meaning that we do have to go hunting occasionally.

--teamonkey

Flying pigs

[Graymalkin]

There are two major problems with RPM and neither have to do with the underlying packaging system itself. The first is a lack of a coherent standard between all of the distros that use RPM as a basis of application deployment. The second is people using an RPM based system installing from a tar.gz.

The reason FreeBSD and Debian's packaging systems run so well is package maintainers know where the hell shit is supposed to go. If I build a port or dpkg I know where my binary, its configuration files, and man page are going to go. I can also be reasonably sure that all the other software on the system has been using the same system as me so I can assume dependancies and whatnot will be taken care of. Some RPM based distros or just old ones people happen to be using may have subtle but important file system and packaging differences. I know I can build an RPM for a default RedHat build but do I know SuSE has everything in the same place? What about some RedHat derivitive or just newer or older version that switches shit around? Since I'm not going to install 20 different Linux distros I am going to build against what I'm using.

The second problem crops up in a couple different ways. When a program is released without an RPM requiring users to either install binaries or source from a dumb archiver it breaks the rest of the RPM system. People end up with shit they cannot manage on their systems because the dumb archivers don't have any centralized management system. Hopefully there's a Makefile included to handle installation and uninstallation. Then there is the problem of people getting source RPMs and not knowing to fix the .spec file to work on their oddly configured system.

The suggestion RPM based distros find a common ground is something that has been known for a long time but has yet to be effectively implemented. You can be different and unique by using Linux while still being practical and using a distro with a coherent design.

The real problems in RPM

[Captain Zion]

I worked in the initial effort to port apt to RPM, and I can say that 80% of a smooth upgrade process is not in the package manager you use, but in the way you package your software. To allow smooth upgrades, you must package software with upgrades in mind, otherwise it simply won't work. Dpkg's design offers some advantages over RPM, but even so it's possible to have smooth upgrades with RPM.

The author summarizes his article in the following points:

• An RPM-based distribution is risky to upgrade.
  That is usually true, but it's not the usage of RPM that makes it so, but the lack of a strict packaging policy. Applying the Denian policy to a RPM-based distro can make it much easier to upgrade. On the other hand, using .deb without following Debian's policy would make a mess out of it.
• A more complex binary RPM package is often hard, if not impossible to install.
  This affirmation makes no sense at all. If it was correctly packaged for your distribution, it will be as easy to install as any other package. If it was designed for a different distribution, it can also happen with dpkg packages. Please note that the package manager offers a mechanism to deploy binaries, all the rest is policy.
• The incompatibilities between different versions of the RPM Package Manager added anotherl ayer of complexity.
  True. RPM is a mess in the point that it is not an implementation of a design, it is being continually modified in both design and implementation. RPM needs to be stabilized, continuing development should go to a different product.
• The developers are forced to consider differences between distributions and create multiple binary packages.
  Not RPM's fault. It would happen with .deb packages if multiple major distributions used it with conflicting policies.

From my experience in the past few years, here are the real issues with RPM:

1. Binary packages are not compatible between distributions, unless they're statically linked and conforming to some kind of packaging standard. Dependency to libraries doesn't mean much: that particular library can be compiled with different options in different distributions. It's not RPM's. Assume that distributions are 100% compatible only because they share a package format is a mistake. Third-party, distribution-agnostic packages should obey a policy shared by all distributions, and that's one of the major points behind UnitedLinux.
2. Allowing multiple version of the same package to be installed isn't a good idea at all. Packages are different in nature, some will allow multiple versions, others won't (e.g. binaries vs. runtime libraries). Doing so only makes the upgrade process harder. Debian simplified it using a good packaging policy. Note also that, even in runtime libraries, you should replace versions that have binary compatibility. If you don't explicitly set a soname in the package name, this information is not available at the upgrade time.
3. Very confuse, non-intuitive pre- and post- install execution order.
4. Transaction processing and dependency resolution is too slow, due to file dependencies. As stated above, file dependencies should not be abused, and that can only be enforced by a policy.
5. Too many unnecessary or confuse packaging features, such as triggers. If you have a good packaging policy, you will never need triggers. Read the librpm sources and you'll find hard-coded dependencies for a number of packages. That's stupid, and a symptom that you've done something very, very wrong and didn't notice it until it was too late because you didn't have a packaging policy.
6. Moving target. Please stop adding features to RPM and modifying existing behaviour, otherwise we'll be always fighting against the package manager while trying to make smooth upgrades happen.
7. Immediate configuration of packages after installation in a multiple-package transaction. Dpkg's deferred configuration is a better strategy.

Most of the other RPM problems everyone says when touting Dpkg's superiority are myths and can be emulated with RPM (even using Debian's alternatives or debconf with RPM -- diverts is something more complicated to emulate). Dpkg is indeed a superior package manager today, but what people usually see is result of Debian's policy and not a package manager feature per se.

Re:There is nothing wrong with RPMs. Only packager

[Motor]

My second pet peeve with RPM is that you need to be root to build an RPM from source.

No you don't! I regularly build packages from source in my home directory. I've occasionally had silly failures because the person who built the srpm hard-wired /usr/src/redhat into it... but that's (as the start of this thread tried to make people understand) the fault of the maintainer. Not the package format.

Re:Just got ADSL, Just had a nightmare with packag

[greenrd]

Well, UNIXodbc is just for connecting to ODBC databases, I think, and there are some others that are unnecessary. Dependencies don't always mean "You absolutely must have it", they might mean "there is one obscure tool/feature you will never use in this package that depends on this lib". If you know you're never going to need to do that, you can just ignore it - resolve the dependencies you do need to resolve first, and then enable the --nodeps commandline option.

If it breaks, you know you do need to install the missing package(s) after all - that's my approach :)

Binary Distros Are Dead

[FreeUser]

Well, not quite, but now that I've got your attention... :-)

It isn't the packaging format really ... most of the issues raised are inherent to binary based distros, which with todays processors really should become a thing of the past.

Source Mage and Gentoo[1] are two excellent source based distros that avoid these classes of problems altogether, and unlike RPM (or debs[2]) add no burden to the upstream software developer.

Shawn Gordon of The Kompany touches on this when he says (from the article, you did read the article, right?)

So rather than providing a myriad of different binary RPMs for the dozens of different Linux distribution, The Kompany, which is a commercial entity developing Linux applications, reluctantly decides to give away the source code to paying customers. [Emphesis added]

Source based distros like Gentoo and Source Mage have packaging systems that automate the process of downloading, configuring, compiling, and installing all of the software on their systems from source (pedants will note there is the occasional binary package, e.g. NVidia drivers, but for the vast, vast majority of software my point holds). Indeed, this approach makes the packaging system itself less important (so long as it works properly) than the overall engineering and organization of the distro itself, and completely irrelevant to the software developer (as it should be).

This has a couple of disadvantages, and a whole bunch of real advantages. So much so that almost no one who has used a source based distro will go back to a binary based distro once they've tried it, despite the cons (in fact, of the numerous people I know who've tried Source Mage and Gentoo, both very different from one another BTW, I know of not a single person who has gone back to their old binary favorite, be it Suse, Mandrake, Red Hat, or Debian).

• • CONS of source based distros
    
    
  • Initial install typically requires source to all of the system, which is generally downloaded from the net. I.e. in most cases requires a fat pipe for installation.
  • The installation is time consuming, due to the fact that each package must be compiled. For modern CPUs this isn't such a big deal (a day will suffice, most of which you can spend away from the computer while it chugs away), but for older CPUs like an AMD K6 233 I have, the initial install can literally take days.
• • PROS of source based distros
    
    
  • Updates and upgrades typically require much less bandwidth than their binary equivelents, as only the new package's source needs to be downloaded.
  • The software is compiled optimized for your hardware. Typically such systems run 20-30% faster than their binary equivelents, based on some casual benchmarking I and a few others have done.
  • The software is compiled against the exact library versions installed on your system, so no subtle incompatabilities arise due to slightly mis-matched binaries. This eliminates a whole class of bugs, and a whole host of problems that can affect stability and reliability.
  • In the case of Gentoo, you have very precise control over the configuration of your system, and what is installed vs. what is not, as well as where it is installed to.
  • In the case of Source Mage, the system is auto-healing, meaning that if and when a new library is installed and the older one removed, all packages that rely on that library are recompiled against the new library. This makes upgrades (on Source Mage) very easy.
  • Upgrades are very easy. In the case of Source Mage they are virtually automatic (you select the package to update and everything is taken care of for you), in the case of Gentoo they are less automatic and require some care, but are nevertheless easier than with any binary distribution I've ever tried (and I've used all the major ones at one time or another), and with Gentoo the flexibility of having multiple versions of libraries and even runtime apps is very useful.
  • Security is improved in one way: the ease and ability to keep up with security updates. Binary distros are still trying to get this to work smoothly (and mostly not succeeding, or requiring a tradeoff like Debian Stable, in which one must run 2 year-old software to enjoy that level of security). This is really a side effect of the previous point, but is significant enough to deserve sepearate mention.
  • The ability to run current hardware. Again, this goes back to the ease and stability of upgrades inherent in source based distros like Source Mage and Gentoo. Source Mage had X 4.2 out a day after its release, giving its users the advantages of all the new features and bug fixes it had to offer. Ditto for KDE 3. Gentoo had these packages out almost as quickly. This means users get the latest features, and the latest bug fixes, almost immediately, in contrast to binary distros that typically require 3-6 months (worse for some distros. I still recall the Debian developers irate answer to a user's question on when thye could expect X 4.2 support in the experimental version of Debian ("unstable"), to the effect of "leave me alone, it will be months!")

There are numerous other advantages I could add here, but you get the idea.

The entire article on the flaws of RPM might better be entitled "The Flaws of Source Based Distributions" which, in the age of Free Software and source code availability, coupled with todays fast processors, really ought to become a thing of the past. In fact, it wouldn't surprise me at all to see Debian, Suse, Mandrake, and Red Hat all embracing the notion of source-based distros sometime in the future ... as processors get even faster, the day long install (on my dual 1 GHz P3), which has already shrunk to less than half a day on the dual 2GHz Athlon I have at work, will shrink even more, to a couple of hours or less.

And the advantages in speed, stability, and ability to keep current with new software releases in a timely manner will only become more acute as time goes on.

So while binary based distros are by no means dead (despite my rather provocative headline), it is my opinion that the writing is certainly on the wall, and the ovservant person can already mark the shifting change in the wind.

[1]There are other source based distros as well, including Linux from Scratch and Lunar Penguin, and likely others as well.
[2]Though in fairness the Debian developers take up most if not all of that burden

Re:Binary Distros Are Dead

[MSG]

Updates and upgrades typically require much less bandwidth than their binary equivelents, as only the new package's source needs to be downloaded.

Source is almost never significantly smaller than binary, and often is bigger. Consider bash:
-rw-r--r-- 26 root root 701486 Apr 16 21:14 /var/ftp/mnt/valhalla-i386-disc1/RedHat/RPMS / ash-2.05a-13.i386.rpm
-rw-r--r-- 24 root root 2144412 Apr 16 21:14 /var/ftp//mnt/valhalla-SRPMS-disc1/SRPMS/bas h-2.05a-13.src.rpm

the system is auto-healing, meaning that if and when a new library is installed and the older one removed, all packages that rely on that library are recompiled against the new library.

In the case of rpm or dpkg, the system protects itself from damage caused by replacing a package that others depend on. Attempting to do so will result in a list of all of the packages which additionally need to be updated to work with the new library. If you're using apt (for dpkg or rpm), attempting to update a library will fetch binary upgrades for the packages which need it. Source Mage doesn't have the advantage here.

...the day long install (on my dual 1 GHz P3), which has already shrunk to less than half a day...

Day long? I don't know many with anywhere near the time for that. I can install a Red Hat Linux server on a clean box in all of two minutes from initial power up to fully functional reboot.

Re:Binary Distros Are Dead

[mattdm]

Distros like Debian GNU/Linux and Red Hat Linux don't take a while to release (to take your example) the very latest XFree86 4.x because of some inherent slowness in putting together binary packages. It takes time because they test new releases before dumping them out there.

I'm also skeptical about your casual benchmarks. On Red Hat Linux, for example, key system elements like the kernel and glibc *are* selected based on your particular CPU. Almost everything else is compiled with -march=i386 -mcpu=i686 -- that is, optimized for i686 but still able to run on older systems.

Re:Binary Distros Are Dead

[BrookHarty]

I tried gentoo also, wanted the speed, but 1.3a has gnome2 and gcc3.1 which I want (AA fonts!). Problem, compile errors. Gentoo has been pretty quick on fixing the errors, but your stuck till they fix it. Another down point, takes some pretty heavy bandwidth to do an initial install. Same problems with Ports on freeBSD, some of the ports are broken, so your stuck, and need little more bandwidth.

Ive been using mandrake, and then I grab the cooker rpms, and try to figure out which ones to install for gnome2/gcc3.1. So far its been ok, but not an easy task. urpm mandrake tools help on which rpms have which files, but rpm should includes these. Ill nail my list of concerns, some are common.

1. rpms should list dep rpms. (this is my major bitch)
2. rpm installs should use the opt directory for major programs. /usr/bin and /usr/X11R6/bin is not a dumping ground.
3. take bandwidth in consideration, dont make users download every locale, doc, extra themes. Allow a "lite" version to work. 85% of the public still use modems.
4. allow updates for cooker/beta rpms. you should be able to install gnome2 with a gnome1 system, and have both work.
5. update rpm databases with cooker rpms
6. ease of use, how many commands do you really use in rpm? add/remove with verbose, list files in rpm, list deps. why would you use grep to search an rpm? rpm -qa | grep blah, rpm should include pattern matching.
7. rpm database should include locations on the net for cooker, beta, etc rpms. An updated database. Microsoft updates work flawless with mirrors, we need this on linux distros. some kind of rpm -install-net bob.i386.rpm
8. graphical/ncurses gui. ya ya, command line is king, but cant we pretty up the install process a little? Even if its a wrapper to rpm, it would go along way to make things easier.
9. -ivvh options, when installing its nice to see which files are installed, and a progress meter, but can we meet somewhere in the middle, just list the files installed, and give a percentage number in front of the line? I hate scrolling back 40 pages on an install just to see the 10 lines of data I needed.
10. group rpms in directories, even if its only 10 directories like slack or use gentoo sources, anything that has 20 plus rpms should have its own directory. I like how SuSE uses symlinks on its filenames, you could do the exact thing with 1 directory of symlinks point to the sub directories with the groups. Easy for a release.

Anyone else notice the rpms that are current on rpmfind.net are from the PLD (Polish Linux Distribution)? Why are the Poles doing a better job than other distros! Mandrake makes 2nd on updated packages.

rpm its not a program, its an adventure.

-
CS under linux, does your cheat scanner block linux? YES.

Re:Binary Distros Are Dead

[rseuhs]

The software is compiled optimized for your hardware. Typically such systems run 20-30% faster than their binary equivelents, based on some casual benchmarking I and a few others have done.

What benchmarking did you and few others do? (And what CPU do you use?)

20-30% sounds a bit high for me.

Thanks for any details.

Re:Binary Distros Are Dead

[AME]

rpm -qa | grep blah, rpm should include pattern matching.

Why, exactly. I think you've profoundly missed the point of the command line if you think that every utility that might benefit from pattern matching should reimplement it.

If you really do that a lot and despise the extra typing, try something like this:

alias findrpm="rpm -qa | grep -i"

Re:Binary Distros Are Dead

[drinkypoo]

The FIRST machine takes about a day. After that you can build a stage3 ISO for your platform (the only one provided is i686, which will suit most people's needs anyway) which will give you a fully functional gentoo system. Then you can install all the packages you need as binaries built on other systems, as long as they have the same architecture, or a subset (IE, you can run the i386 binaries on your i686 or whatever, but K6 binaries won't run on your i686, or vice versa.)

Re:Binary Distros Are Dead

[Anomie-ous Cow-ard]

most of the issues raised are inherent to binary based distros

• Poor dependencies. Nope, not inherent, and can hit source-based distros too.
• Poor upgradability. Nope, not inherent, and can hit source-based distros too.
• Incompatible changes to the package format. Nope, not inherent.
• Incompatible file locations. Nope, not inherent, and can hit source-based distros too.
• Upgrades can break things. Inherent, but hits source-based distros just as easily.

Ok, perhaps i missed something in the article. Where are these issues inherent to binary distributions that source distros don't suffer from?

The software is compiled against the exact library versions installed on your system, so no subtle incompatabilities arise due to slightly mis-matched binaries. This eliminates a whole class of bugs, and a whole host of problems that can affect stability and reliability.

At install. However, wither you lose this when you upgrade the library, or you have to recompile every single app that uses the library whenever the library changes. Damn, i would hate to upgrade anything X depends on in a system like that, 2 weeks until the upgrade is complete! (assuming my old box doesn't run out of disk space first).

A non-stupidly-written library will be very easy to handle in dependencies (remember, minor version changes indicate backwards-compatible API changes, so app recompile shouldn't be necessary), a stupidly-written one somewhat harder. Either way, a good packaging system can easily handle this modulo human error. In fact, there's less chance for error when a few knowledgeable people handle all the compiling, as opposed to having everyone try it on their own. And when something does go wrong, everyone is likely to have the same problem, so more eyes can look for it.

Upgrades are very easy. In the case of Source Mage they are virtually automatic (you select the package to update and everything is taken care of for you), in the case of Gentoo they are less automatic and require some care, but are nevertheless easier than with any binary distribution I've ever tried (and I've used all the major ones at one time or another),

Somehow, i doubt recompiling everything from source (automated or not) is easier than apt-get dist-upgrade. Definately not easier than tracking unstable (as, based on your comments here, you're effectively doing with either of your favorite source-based distros).

Security is improved in one way: the ease and ability to keep up with security updates. Binary distros are still trying to get this to work smoothly (and mostly not succeeding, or requiring a tradeoff like Debian Stable, in which one must run 2 year-old software to enjoy that level of security). This is really a side effect of the previous point, but is significant enough to deserve sepearate mention.

Well, it would be deserving if it made any sense. You're comparing bleeding-edge source distros with tested-almost-to-the-point-of-absurdity binary distros. Try comparing to Debian unstable instead, it would be somewhat more accurate. You also neglect the fact that the updated code needs to be compiled eventually (since source-based pushes this to the user, they get 'release' ahead a little here), tested for breakage (from your description they just throw the source up without any testing, i hope this is wrong), packaged (a little more time here), and uploaded to the repository (which can take some time, depending on procedures in place).

and with Gentoo the flexibility of having multiple versions of libraries and even runtime apps is very useful.

I have multiple versions of many libraries on my Debian system here. A few apps too (e.g. gcc, autotools). I don't really need multiple versions of most apps. Does Gentoo make everything multi-versonable, even when config file formats (.foorc in $HOME, for example) change incompatibly and other sharing problems like that?

in contrast to binary distros that typically require 3-6 months (worse for some distros. I still recall the Debian developers irate answer to a user's question on when thye could expect X 4.2 support in the experimental version of Debian ("unstable"), to the effect of "leave me alone, it will be months!")

On the other hand, you're leaving out the part about X being a very large, very complex set of programs that needs quite a bit of time to package properly and ensure upgrades will actually function. You're also leaving out the part about the X packagers having to maintain the 4.1 version at the same time, especially since 4.2 cannot be tested well enough in time to make it into frozen. Further, you're leaving out the part where all this is done in the packagers' free time. And the part where the packagers made 'unofficial' packages available much sooner, so anyone who really wanted to could use them and help get things to the point of "doesn't explode on install". And the part where various patches from 4.2 have been backported to 4.1 (and the part where 4.2 contains patches originated with Debian's 4.1).

All in all, you've severly damaged your argument with your poorly reasoned claims.

Re:Binary Distros Are Dead

[smallpaul]

If binary distros are dead, does this mean binary-only software packages are dead? And if so, does this mean that commercial developers will abandon Linux and go to platforms that are more disciplined about binary backwards and forwards compatibility?

Re:Binary Distros Are Dead

[7-Vodka]

what are you fucking retarded? when you're transfering source, you can also transfer the diff instead of the whole thing. Try doing that with a binary package.

Re:Binary Distros Are Dead

[FreeUser]

What benchmarking did you and few others do? (And what CPU do you use?)

Nothing terribly official (which is why I used the word casual).

Time to compile the kernel, Time to load X, time to load KDE, the time it takes transcode to encode a 42 minute episode of Max Headroom into xvid format (that was one that experienced nearly 30% improvement over versions compiled on, and run on, Debian, for example).

Architecture for myself is nothing special: a dual 1GHz Pentium 3, compiler flags:

CFLAGS="-march=i686 -O3 -pipe"
CXXFLAGS="-march=i686 -O3 -pipe"

gcc 2.95 gave me roughly 20% speed improvements on every test over my old Debian install, and about the same over my old Mandrake install. gcc 3.04 gave me roughly 25% speed improvements, and gcc 3.1 gave me right around 27% speed improvements.

I actually had the most dramatic speed increase (30.7%) on a dual Athlon MP box compiled with -march=athlon-mp using gcc 3.1. People can poo poo source based, optimized speed improvements all they like, but once you've tried them you'll likely notice the speed improvement yourself, and be reluctant to go back to binary based distros.

Source based distros are a natural evolution, given the source availability of today's best operating systems and utilities (FreeBSD and GNU/Linux). They eliminate a whole class of problems we've all had to contend with, and give us dramatically better performance to boot.

I for one will never go back, and everyone I know who has tried either Gentoo or Source Mage feels the same way, despite the fact that neither of those distros is anywhere near as polished as Mandrake, Suse, or Red Hat.

Re:Binary Distros Are Dead

[MSG]

Yes, you can get the diffs or update from CVS, but only if you're updating by hand. However, that doesn't save any time, just bandwidth. Updates by hand are going to be a HELL of a lot slower even than downloading all of the full source tarballs and building them automatically. Don't forget that with manual updates, you're also responsible for backing up your config files and restoring them after the update. Automated systems all (that I know of) take care of config files automatically.

Re:Binary Distros Are Dead

[rseuhs]

Would you recommend Source Mage or Gentoo? What are the differences?

Thanks again for helping an 'not yet'- source-based Linux distribution user ;-)

Re:Binary Distros Are Dead

[FreeUser]

Would you recommend Source Mage or Gentoo? What are the differences?

First: SAVE YOUR EXISTING XF86Config/XF86Config-4 configuration, and any other configurations that would normally be tedious to create. Source based distros are less polished, and do not configure X for you automatically the way Mandrake et. al. do. By saving this file ("cheating" if you will) you'll save yourself a lot of time on the back end of the source-based install.

That having been said, it is a tough call. Both are excellent, but neither is very polished, and both are still in beta (and thus will have some bugs).

Source Mage's main drawback is that it assumes the 'source-only' paradigm almost to a fault, and has no provision for allowing older packages to remain installed when a newer version is installed. I.e. when you upgrade libpng, the older library is removed, the newer one installed, and anything linked to libpng (that the packaging system "sorcery" keeps track of) is recompiled. This works wonderfully for source-based packages and makes a system very easy to upgrade and keep up to date.

The problem is when one has 3rd party binaries that requires the older library, and one can't recompile the binary against the new library. The deveopers of source mage are working on versioning support to fix this problem.

If you want a source based distro that doesn't involve a lot of manual work to get it running, and is almost a no-brainer to upgrade, you probably want to try Source Mage.

Gentoo is a mirror image of the above. It supports multiple package versions being installed at the same time pretty cleanly, is less source-only centric, and is quite good at supporting legacy binaries (at the speed with which free software moves, any 3rd party commercial binary is likely to be "legacy").

Upgrades on Gentoo require care. Unlike Source Mage you should not run around doing 'upgrade world' commands without examining them first and considering the consiquences. It still isn't as difficult and error prone as Mandrake and Suse upgrades have been (but is arguably about as error prone as typical Debian testing upgrades can be).

In other words, its pretty safe and easy to upgrade, but not a no-brainer and, very occasionally, an upgrade run simply as is with no consideration can break things.

If you want a very flexible system with excellent documentation, and don't mind performing the installation steps required by hand (but documented step-by-step by the distro), then you want Gentoo.

I like them both. I find Gentoo a little more ready than Source Mage for production work, but Source Mage's "auto-healing" function is unequalled anywhere else. What is more, developers for each distro are working to address that distro's difficiencies, so in the long run both distros are likely to have most of the features of the other. In other words, I expect Gentoo will have Source Mage's autohealing functionality in the not so distant future, and I suspect Source Mage will have better versioning support quite soon as well.

My advice? If you have the disk space and partitions available, install them both, try them both out, and pick whichever one you feel most comfortable with. Both are, IMHO, excellent.

Re:Binary Distros Are Dead

[7-Vodka]

cool, sorry about the profanity and thanks for the cordeal reply. I was just waking up :-/

Re:Binary Distros Are Dead

[dvdeug]

CONS of source based distros

* You need a compiler and all the include files installed.

* You often get random changes in what is built depending on what include files are installed where.

* When libfoo1 and libfoo2 can be installed at the same time, but libfoo1-dev and libfoo2-dev have the same files, it's very hard to install packages where one of which depends on libfoo1 and the other libfoo2.

Re:Binary Distros Are Dead

[AxelBoldt]

does this mean that commercial developers will abandon Linux and go to platforms that are more disciplined about binary backwards and forwards compatibility?

Let's hope so.

Re:Binary Distros Are Dead

[MSG]

NP. So was I when I first read the article. ;-)

Re:Gentoo is a giant step, too long for mere morta

[isdnip]

You're right about the forums being friendly; I've been there, and they help. But asking a question and waiting a day or two for an answer can keep the pace pretty slow... I guess part of the problem is that Linux doesn't have a single standard for where things go, so whatever I might have learned doing Mandrake or Redhat doesn't necessarily help.

Yeah, I did Slackware and Yggdrasil back in the 1993-1994 timeframe. But at this point I'm not looking for an educationally challenging experience. I'd like to see a Linux distro that, well, kicks Bill's butt. Or at least is an attractive enough alternative, so that commercial developers don't think that computing is a Redmond monoculture. And that isn't here yet. I appreciate how Gentoo's core users, a self-selected group who are a short step away from "Linux from Scratch", don't want easy. But why not build a friendlier system out of portage?

And yes, the real problem is that linux distros don't have standardized places for things, or fully standarized ways of setting things up. And yes, there are at least some standards. And, as usual, the nice thing about standards is that there are so many to choose from. (Yes, that's supposed to be a punch line, but it's also true.)

On stability & servers.

[mindstrm]

First.. you mentioned it, but I'm not sure everyone got it....

The 'Unstable' in debian terms does not mean the system is unstable, it means the package dependencies are unstable. It has nothing to do with running unstable code. It means that there is no guarantee a change will not break a lot of stuff and not be fixed for a while. It's not uncommon to try to install a package and find the dependencies don't exist yet... or they exist, but are an older version. That's what unstable is all about.

Secondly.. regarding server stability.

IF you build your kernels yourself (you should), and if you are aware of what services are running, system stability is not really an issue.

I know that debian is pretty much the only system where I *don't* run hand-compiled apache, ftpd, etc. You should know what's up in your system. In this respect, no system is more stable than any other.

Re:Gentoo is a giant step, too long for mere morta

[mindstrm]

Wow. Industry wide support. Yay.. just what I've been waiting for.

A linux distribution so messy that you NEED an industry to support it.

okay.. I'm mixing words.. but there is a grain of truth to it.

To think, all these years, the hundred boxes I've run, it hasn't mattered.

Supporting what, exactly? What is this 'industry' that supports RedHat but not Debian? I have yet to find a single piece of software I have needed that did not work under Debian.

Link farms are viable

[HalfFlat]

I guess that a side effect would be for the /usr/bin directory to become composed entirely(?) of links. Still, I've done that already when trying out a new version of Python, and it didn't seem to cause any problems. (I suppose that the other bin directories probably wouldn't be affected that way. Especially /bin and /sbin, since they might be needed when other partitions weren't mounted.

I run a system based loosely on Linux from scratch, which adopts a link farm approach like you describe. My /usr/bin (and /usr/blah directories generally) indeed do have hundreds and hundreds of symbolic links. This probably impacts performance, but I've not noticed it on my K6-3/400 PC with old slow IDE disks. Using some simple perl scripts to create, retarget and clean up symbolic link farms, package management is simple. The key benefit is that the metadata associating a file with its package is the symbolic link itself - it is logically incapable of becoming out of sync.

My work-around for the root file system is as follows. Each package I keep in /usr/pkg/packagename-version. Things destined for /usr/bin live in /usr/pkg/packagename-version/bin and so on. Things which need to end up in (say) /sbin live in /usr/pkg/packagename=version/root/sbin. I cp -a the contents of these root subdirectories into /.

This mechanism is a comprimise, but works quite well. I can compare files in root fs directories against those in /usr/pkg/*/root to find which file came from which package. Updating is a simple cp -a.

Why not do the same for /usr, and avoid the symbolic link farms? Primary reason is that while copying into the root fs those files that need to be there might take up 30MB or so, doing the same for /usr would mean an extra 500MB or more of duplicated data. The other reason is that for those packages which aren't too tied to their location in the filesystem, differing versions can be present on the system simultaneously.

Re:Gentoo is a giant step, too long for mere morta

[mindstrm]

The lack of standards is good, in a way.

From a learning point of view, as a hobbyist system, it's fantastic. You actually learn what is flexible and what is not. I've seen far too many Solaris admins or whatnot who just can't seem to think that something might be in a different directory.. and if it is, it was done 'wrong'.

No No No No No

[unformed]

Packages are way better than Windows setup.exe.

1> Consistency, everything is installed the same way, select what you want, and hit install. (I use Mandrake, and rpmdrake makes it extremely easy to install packages...

2) Non-bloatedness. I'd much rather have 20+ packages for KDE than 1 package. Yes, it'll take me a long time to go through them, but I select what I want, not what the developer thinks I want.

One really cool part about Linux is that I can change --anything--. I don't have to have a graphical interface if I don't want, in which case I don't need to install it. If I plan on using Gnome as my window manager, but want to run koffice, I only need to install the kde-libs package, and don't need all of the kde binaries..

When a small part of a large project changes, I only need to update that small part, instead of redownloading the whole package. Imagine having to download all of KDE to update a tiny KDE app.

Uninstallation is also simple, select the box, hit remove, and there's -no other prompts-.

BTW, There is an installshield for linux, it's any kind of RPM/DEB installer (RPMDrake, apt-get, alien, etc) and it's of a hell of a lot nicer and more consistent than any simlar idea on Windows

Re:No No No No No

[Apreche]

None of those things contradict the idea of having an installshield and using a setup.exe type of installation system. Download quick time for windows. You can A) select what you want B)download only what you want C) it is very easy and consistent D)it updates all by itself. No big re-downloads of quick time. Uninstallation is also simple, add/remove programs. quick time, then 3 clicks.
No, none of those are install shields in the style of windows. Those are seperate programs designed to look at any piece of software and attempt to install it. In windows each piece of software comes with its own installer. Each piece of software is different. Having one installer for every piece of software is a bad idea, because it wont always work. If it doesn't always work, it's worthless to me.

Re:No No No No No

[Webmonger]

You have more control over your system if your system understands what's installed on it. Standardized systems like .rpm or .deb provide this. InstallShield (despite being used by 90% of Windows programs) does not. It turns each application into a big black box. Windows knows how to ask it to uninstall itself, and that's all it knows.

Why do you think there are programs like Uninstall Manager? Uninstall utilities are designed to give the user greater control than application-provided uninstallers. They wouldn't exist if that control wasn't lacking.

I can't count the number of times a setup.exe has offered or attempted to install old versions of Quicktime, Acrobat Reader or DirectX. This is because Windows has no standard way of knowing what packages are installed.

With RPM, you'd have one package for each, you'd download the latest, and that would be that.

With APT, you'd just do apt-get upgrade, and it would take care of the dependencies for you.

The tasks that installers perform are well-known and easy to understand. Even if funky, bizarre commands are needed during the installation process to initialize the package, installers provide the ability to run scripts.

There's no reason why a custom installer is needed, and there are a lot of good reasons why a standardized package management system is useful. But not all package management systems are equal.

Re:No No No No No

[Some Dumbass...]

C) it is very easy and consistent

I think by "consistent" the author meant that different programs install in the same way. There are several different "InstallShield"-type programs for Windows. Furthermore, there are differences between the ways that different programs install. Some programs install in Program Files, others make a directory right off C:, and a few install in other places (C:\windows, for example). Even among the these groups you have variants. For exapmle, some programs install in a directory named for the program while other programs install in a directory named for the vendor. There are even some variations on this (stuff like C:\Program Files\Corel\Office\programname).

A lot of this could be fixed, of course, if vendors stuck to some standard, like "Install in C:\Program Files\programname". But the same could be said for RPM as well.

Re:No No No No No

[unformed]

A) select what you want
Uhh...that's the whole basis behind rpms.

download only what you want
see above.

it is very easy and consistent
No, each installshield is different. Installshield is a *programming language* but as you're not a coder, you don't know that. Also, not all applications use installshield, because it is pricy as fuck. Some create their own installers; some use Wise, some use nullsoft's installation system, etc, etc. Also, you have to download a seperate binary for each program. An installshield executable add about a meg to the setup file. Not very efficient when the program is about 500k.

Everything you want, rpmdrake does:
1) You select a cooker/contrib/other http package repository. Update the file list, then select what you want to install/update. rpmdrake then automatically downloads all needed packages and installs them.

2) You talk about how programs are different and need to do certain things differently. Yes, and thats why RPM supports running scripts during installation. Of course, being that it's powerful, you're allowed to disable running scripts for security purposes. You can also use cpio to extract all the files without installing them, so you can look at them yourself, before you go installing things while in root.

Regarding, installers always working, if I remember correctly, things in Windows don't always work correctly. If I remember correctly, I got a BSOD while installing Win98. How convenient.

You obviously don't use Linux, or if you do, don't know jack about. You've also stated that you're not a programmer, so you don't know how things happen behind the scene.

That said, since you don't know what you're talking about, STFU.

Re:No No No No No

[unformed]

They do. Don't select "Expert" install, or "Individually select packages" in Mandrake's initial install.

Re:haha, LOFL!

[sg_oneill]

As opposed to multiple points of failure? There are a good many nukable files in /etc that'll cause linux to bork at bootup.

That said one can get in via alternate methods and fix, but what a horror. One should back that etc dir regularly btw, windows does it automatically "Last good configuration". Woohoo.

Of course windowss still sucks ;)

it's not a problem with RPM

[g4dget]

RPM is really no worse than DEB or any of the alternatives. If anything, its file-based dependencies keep you out of trouble a little more. RedHat wouldn't magically work any better if they switched to DEB.

What makes DEB files work so well is that there is usually a single bottleneck that they all go through: the Debian organization. That's where they all get tested for whether they can be installed. You may notice that DEB files are almost never distributed separately. If they were, then users would have the same problems with them as they do with RPMs.

Systems like Gentoo really don't solve the problem either. Using source merely reduces the frequency of dependency problems, not their fundamental source. That, again, may be a practical tradeoff, but you also pay for it.

So, by all means, run Debian: it really does work better. But it doesn't work better because of the packaging format, it works better because of the organization behind it and because people generally just don't do third party package distribution.

Re:standardized Linux configuration files...

[SN74S181]

The other problem is, Linux is a Unix clone, and there is a long slowly-evolved configuration system for Unix that reaches back in history. It works, and it works well.

I don't run any Linux machines any longer, and I would be enraged if somehow the 'we must make it easy to use' Linux people started trying to force a big 'standardized' structure down the throats of the larger Unix community. I switched to NetBSD in part because it's cleaner, it follows a tradition (all those O'Reilly books I've been collecting for years actuall MEAN SOMETHING), and it always works. Rather than installing and learning 'new-widget-number-twentyseven' to accomplish some admin task, I just research the way it's always been done, and it works.

To put it another way: we're in trouble when things have gotten so crofted up that you can't start out researching a problem in AEleen Frish's 'Essential System Administration' and all the other O'Reilly classics.

Re:Talk about a gimmick

[walt-sjc]

This is not the issue. It has NOTHING to do with the compiler. I have played with both sorcerer and gentoo and problems with it were that the distributions were never stable, and things frequently broke due to the constant state of flux. They had no concept of debian's stable, unstable, and testing branches. Basically, package maintainers didn't test - changes were made on the fly to be "current". Multiply that by the number of package maintainers. While this is fine for playng around, it's totally useless for a business and THAT is the problem with those distros.

So while I agree that these distros are not as good as they sound, I disagree on the reason why.

Compiling from source gives you a ton of flexability. Most larger packages have LOTS of compile time options which can be tweaked. Looking at apps like sendmail, apache, samba, etc. each has optional modules you can use. Binary distros limit you to the options the distro maintainers include and that's it. Optimizing for your processor can make a huge difference in the performance of many apps such as media players, graphics manipulation, the X server, the kernel itself, etc.

I started with slackware about 7 years ago now, migrated to RedHat, got frustrated with RPM and dependancy hell, played with MANY distros, and finally settled on debian. Debian rocks. It's the best of the bunch in terms of package management, stability, package diversity, user support community, processor architecture diversity, etc. I prefer debian's package management over any other system I've used including any of the BSD's, AIX, solaris, hpux, OSX, and a few others.

Your mileage may vary...

My one gripe

[cjpez]

The one thing that I really don't like about any package manager is rigid dependency checking. It only really occurs when you try to act outside of the "accepted" package system. For instance, back in my Redhat and then Debian days, I was content to let the base system get installed by RPM or apt. I also loved, especially in Debian, the ability to use apt to just install an app I wanted to use. However, for a long time, I used the DRI XFree86 that came from CVS and got compiled by hand. So I was stuck with two options - either don't install the X packages, or install them anyway but install X by hand on top of it. In the first case, it was really difficult to install any package that relied on X. On RPM, I had to turn off dependency checking to do it (which meant that the primary purpose of the package management system was bypassed, IMO), and with apt, it was nigh-impossible (I never did figure out how to get apt to install something despite dependency issues). On the second case, whenever the package management system decided to upgrade my X, then my hand-installed stuff would get overwritten.

What I'd love to have in a package manager is a more intelligent dependency check. Like, instead of just saying "I need this version of X," it would also just check for the existance of /usr/X11R6. Or if a package requires BerkelyDB, after checking "inside" the package manager, just try and see if there's a libdb.so somewhere in the LD search path. And then mark down "inside" the package management system that the "BerkelyDB" or "XFree86" dependency seemed to be fulfilled by a manual installation.

That would be the ideal system for me.

rpm/deb solves the wrong problem

[jilles]

The key to figuring out why a particular solution is not working is trying to figure out what problem it is trying to solve. Why do we need a package format like rpm? Because linux applications tend to consist of a lot of files which need to be put in the right places. Doing this manually takes time and is error prone. Types of files may be icons, images, executables, man pages, fonts, .... In addition to these files scripts are bundled that may do configuration, clean up after removal, move files to the right directory etc. Making this work requires that the creator of the package makes a lot of assumptions like where do icons go on this system? What is the right place for an executable? Where do the man pages go? How do I add a menu item to whatever window manager is installed? ...

Efforts to improve package system have focused on providing answers to such questions: standardization. Standardization is good but if you take a step back you realize that it is not relevant to provide answers to these questions. Specifying that this or that icon should go to some kde specific directory is totally wrong. It is the task of the package manager to provide such information, not to require it. All the package should provide is an icon.

A package is a set of files with some meta information, not a set of files that scatter itself all over the place based on some assumptions the package creator made. Given the meta information and the files the package manager should do the rest: copy files, insert menu items in relevant menus, etc. This is how apple bundles work. Another example of this approach is the war package format for servlet applications.

There's a lot of debate on whether .deb or .rpm is better. IMHO they are equally flawed. The only reason .deb works better is because there are fewer .deb based distributions (i.e. debian and a handfull of very small debian derrivatives). The .deb format is not plagued by differences between distributions because there's effectively only one distribution: it avoids the issues rather than solving them. Try unleashing potato based kde .debs on the latest unstable debian and you will find yourself in .deb hell (ironically most debian potato users end up trying to do the reverse: install the latest kde .debs on a potato system).

Re:rpm/deb solves the wrong problem

[jilles]

Eeeew!!!!, compile time fixing of deployment directories! Compilation != configuration management. The fact that it is for most unix programs is the problem, not the solution.

A registry would be the simple solution. A better solution is an ldap configuration database. Information like where icons are supposed to go should come from such a database, not from compile time flags and certainly not from a binary package.

Re:rpm/deb solves the wrong problem

[jilles]

Been there, done that. Lets just say it does not work as advertised. IMHO it fully deserves the label unstable.

DLL Hell

[sheldon]

Wow, you've just described a huge aspect of DLL Hell on Windows...

DLL Hell can also be solved by intelligent people setting up install packages... Strange how that never works very well in practice.

Re:DLL Hell

[wowbagger]

Hence why I mentioned the Beast in one of my earlier posts.

The reason I keep making this point every time it comes up is that I don't want to see people trying to solve the wrong problem the wrong way for the wrong reasons, and then wonder why things aren't any better.

The "all in one Setup.exe" solution someone proposed above, the "Ditch RPM, use .DEB" crowd, the "Just Build From Source" - they all miss the point that the problem is the fact that package maintainers DON'T! They DON'T maintain binary compatability until the next major rev, they don't make their dependancies correctly, they don't keep their files neatly organized.

I'm just afraid that somebody will bring out some new, shinier, bluer package system that "solves the problem" and everybody will leap upon it with glad cries until they realize that the problems are the same, because we didn't solve them in the first place!

On LKML, Linus raked the DRI developers over the coals for not maintaining backward compatibility with the various version of the DRI. The DRI guys, in their (understandable) rush to make things stronger, faster, better didn't understand the importance of keeping compatibility. It took a BOFH to LART them into realizing the importance of that.

I just home somebody will serve as that BOFH for all the package creators out there - be that BOFH the Debian crew, RedHat, IBM, or even The Dark One Himself.

Re:There is nothing wrong with RPMs. Only packager

[joestar]

I have to say I have never any problem with Mandrake 8.2 and URPMI while I use packages repositories made for 8.2 (= the 8.2 RPMS + 8.2 RPMS contribs + third party packages made for 8.2). So in this way it's really the same as Debian. Of course, sometimes when I try to install a development package from Cooker it will lead to issues, but as a normal user I'm not supposed to do that. And it's really very clean, see:

1- Install a single package:

# urpmi koffice
% Total % Received % Xferd Average Speed Time Curr.
Dload Upload Total Current Left Speed
100 8461k 100 8461k 0 0 61958 0 0:02:19 0:02:19 0:00:00 63912
installation de /var/cache/urpmi/rpms/koffice-1.1.1-14mdk.i586. rpm
Preparing...
koffice
/* note: status bar removed because of the Slashdot junk chars filter */
[root@europe ]#

2- Install a package with dependencies :

# urpmi php
Pour satisfaire les dépendances, les paquetages suivants vont être installés (1 Mo):
php-common-4.1.2-1mdk.i586 php-4.1.2-1mdk.i586
Est-ce correct ? (O/n) o
% Total % Received % Xferd Average Speed Time Curr.
Dload Upload Total Current Left Speed
100 481k 100 481k 0 0 56191 0 0:00:08 0:00:08 0:00:00 63824
100 23587 100 23587 0 0 23469 0 0:00:01 0:00:01 0:00:00 59532
installation de /var/cache/urpmi/rpms/php-common-4.1.2-1mdk.i58 6.rpm
/var/cache/urpmi/rpms/php-4.1.2-1mdk.i586.r pm
Preparing...
php-common
php
[root@europe ]#

3- Uninstall a package with depencies :

# urpme php-common
Pour satisfaire les dépendances, les paquetages suivants vont être désinstallés (1 Mo):
php-common-4.1.2-1mdk php-4.1.2-1mdk
Est-ce correct ? (O/n) o
[root@europe ]#

SRPMs

[Al Al Cool J]

I'm amazed the article doesn't mention SRPMs which I've found to be a very reliable way of getting the newest and latest software to work on my Mandrake 7.2 boxes. It can be a pain getting all the *-devel packages you need, but once you do, you get your own nice shiny RPM that you can drop onto on any identical system that you're running.

What scares me off using something like apt-get is that my home computer is on a dial-up. I don't want to unleash some automated system that's going to go and stupidly try to jam 50MB worth of packages down my pipe. With RPMs I can control how much gets downloaded and when. And I have the nice SRPM fallback when things don't work.

How easy is Debian to maintain on a dial-up?

It is not a problem with RPM

[Priyadi]

If you take a look at comparison of various package management (http://www.kitenet.net/~joey/pkg-comp/), it is clearly shown that RPM and DEB have almost the same set of features.

So, why installing an RPM is a more hassle that installing a DEB?

Because there are more distributions using RPM, while DEB is used almost exclusively on Debian. Yeah I know there are Progeny and Storm, but they are not very popular and are using a sizable part of Debian itself anyway. When somebody decides to make a DEB package, he will make sure his package will work with Debian (and Debian only), and he can be sure that everyone that downloads his deb will be installing it on a Debian system. But when another person decides to make an RPM package, with current situation it is a very hard job to make sure his package are compatible with various version and various distribution.

This problem will be gone if every RPM based distro are following the LSB. Even if they are all following the LSB very religiously, it is still possible to encounter this sort of problem. Say a person is using a LSB 1.0 compliant distro, but he downloads an RPM package compiled for LSB 2.0, it still won't install on his system. But still LSB is a lot better than forcing a distribution monoculture to all Linux user.

Re:It is not a problem with RPM

[prockcore]

"So, why installing an RPM is a more hassle that installing a DEB?"

Is it? Or is it that RPMs are just more widely used?

Here's an example, one of my coworkers was installing Debian 3.0 Untested on a box.. for some reason, Debian did NOT add the untested paths to apt-get's config files. Therefore, whenever he tried to install new software, it wouldn't get the proper debs for his system.. there were ludicrous things like not being able to install mysql-client because it relies on perl5.0.5 (he had 5.6 installed) As far as I know, 5.6 is backwards compatible with 5.0.5. But Debian still insisted that 5.6 wasn't good enough and wanted to uninstall it and install 5.0.5

Of course this nightmare was all fixed when we realized that it wasn't getting the untested packages but rather the stable packages.

Now you can say blah blah blah that's why it's untested.. but if you actually looked at my example, you'd see that mysql-client from STABLE requires perl5.0.5, not perl5 or above.. but a specific version.

Re:It is not a problem with RPM

[bruckie]

This problem will be gone if every RPM based distro are following the LSB. Even if they are all following the LSB very religiously, it is still possible to encounter this sort of problem.

Um... were you drunk when you wrote this?

--Bruce

Re:There is nothing wrong with RPMs. Only packager

[Webmonger]

Actually, there is a limitation of .rpm that hinders the APT4RPM functionality-- file dependencies. .rpm archives depend on specific files, while .debs depend on specific packages. This can be worked around, essentially by creating a list that maps files-that-are-depended-upon to packages-containing-these.

But yes, there is at least one technical superiority of the .deb file format. I have never heard any argument that .rpms have a technical superiority to .debs, so I have to wonder: why don't RPM-based distros don't switch to deb? They could just adopt the .deb file format as RPM 5, make the tools speak deb, and stop worrying about it. They'd serve their users better and reduce duplication of effort.

Or perhaps users should take it into their own hands. Using tools like 'alien', it might be possible to take the apt4rpm approach one step further-- create an unofficial 'Redhat .deb' distribution-- the same packages as Red Hat, but in a different package format.

KDE is not gnome

[rseuhs]

Can the RedHat users please stop claiming that KDE is cloning the registry?

KDE users configuration files like most other Unix-software.

There are some things debatable about the location of these files (in $KDEDIR/share/config and ~/.kde/share/config) but thankfully it's not even close to being a registry.

There's a utility called alien

[Accelerated Joe]

You wrote:

I've never had a problem locating a .rpm though.

Then you should look into a program called alien. I've used it to install some things that didn't even have public source (like ViaVoice from IBM). It was totally painless. Too bad you gave up on Debian so soon. :-(

The article doesn't answer point #1!

[Papineau]

All the solutions the author seems to prefer (basically, switch to another distro, not RPM based, or use tools which need some distribution repositery to handle dependancies) doesn't answer point #1: How to install a random binary RPM which has dependancies not present on the system?

Switching distro might help you about the "dependancy hell" of RPM, but then (as the author notes) you're at the mercy of the packagers of your distro to make it available to you. What's the difference between that and being able to only install a RedHat compiled RPM on a RedHat system? Or a Mandrake compiled RPM on a Mandrake system? You still have only one source of packages which "will work". It might be a bit easier with tools like apt-get, urpmi, apt-rpm and apt4rpm, but your distro (or some other repositery) still needs to manage the dependancies during the build and install processes. And they select what you can install (by rendering it available or not).

I don't think the problem lies in the RPM format itself (although, again as noted by the author, RedHat has sometimes changed the format without backwards compatibility). What's needed is more resemblance between the layout of the filesystem, like what the FSB and LSB (although there's more to it than only FS layout) try to put forward. That's what will make it easy to install random binary packages found on the Net, which is the core of the article.

To the contrary of M. Shawn Gordon (the Kompany), I don't see a problem with different places (among distros) to put the same software. If it's something that can be in multiple places, there's usually a foo-config script which will tell you everything you'd like to know about it. The packagers just need to learn not to hardcode paths if it can be different among users, and use the foo-config method instead.

And what's the problem with putting the RPM build area in /usr/src/what/ever? Once it's installed with rpm -i, or even built from source with rpm --rebuild, the spec file doesn't need to know where it is, it will be in the right place.

Personally, I use RH since 4.2. I just upgraded from 7.2 to 7.3 yesterday. I admit I didn't used the normal way (which is reboot with install CD, choose upgrade), but the longest part was still to actually install the packages from CDs. And I've got quite a bit of packages manually upgraded (normally rebuilt from source by me) from the original developers rather than RH. If those where more recent than what RH packages, it kept what was on my system before (eg, Mozilla 1.0.0 rather than 0.9.9).

Also, making a spec file is rather easy. And if you use the %configure et al. targets rather than directly call configure, a whole lot of options about the placement of files will be fed to configure for you (depending on your particular distro). Not sure which version of RPM introduced it, nor if other distros use it besides RH, though. There's even a way to build an RPM from a source tarball (although I'm not sure if you need a spec file inside the tarball or not, as I never used that way).

ftp.kde.org/pub/stable/mandrake/3.0.1/8.2/

[oliverthered]

I ended up getting most of my packages from there, but there's no kdevelop or koffice in the 3.0.1 directory for mandrake.

If there was a reasonable standard base I would have used a suse packege.
Would have known that the packeges were at ftp://whereever,

And that still leaves the question open , why MYSQL?

IMHO RPM's need a MSCW rating system for deps.
Must have glibc>34
Sould have ....
Would like to update/install mysql as well.

Fix, don't criticize.

[IGnatius T Foobar]

The reason RPM is the most popular package manager out there right now is because it's the best. Sure, it's got some problems, but writing a whiny opinion piece isn't going to solve them. If something better gets written, something better will get used. It's that simple.

By the way, as someone mentioned earlier, dependency hell is created by poor packages. LSB should fix that; keep in mind that on an LSB-compliant system you will be able to look for a single dependency called lsb-1.0 (or whatever future version) and if it's found, you may safely assume that the system has all of the components which make up an LSB-compliant installation (libc, libz, etc.). That by itself should alleviate a lot of installation headaches.

In the future, though, I think we're going to see a lot more automated install programs. Ximian appears to do it seamlessly (unfortunately, I can't use it because I prefer KDE). I've also seen others, such as OpenNMS, do the same thing. And then of course there's the online version of CPAN that just goes out and grabs whatever it needs.

I realize that the ubergeeks among us will scream bloody murder at the thought of an installer program updating and installing libraries without asking permission. For those of us with that concern, we'll continue building stuff from source so we know exactly what's there. But for Linux's increasingly less techno-savvy user base (like it or not, folks, the Windows world is slowly starting to wake up and move to Linux) you have to make it easy.

Re:There is nothing wrong with RPMs. Only packager

[mandrews]

I must agree whole heartedly with this comment.

I'm a redhat user myself, and have tried downloading binary RPMS and seen RPM-hell first hand. I found the same solution: download the source RPMS!! A quick rpm --rebuild package.src.rpm will usually do the trick.

I have seen some cases where this does not work (some developer wants the latest ALPHA version of some library). For this I blame the developer, not the distro.

RPM is ok

[lameruga]

Yeah, there is couple of problems with RPM, but:

- it's easy to do upgrades (on RedHat, don't know about others) I do it several years from remote location, and only once it failed because of bad LILO configuration...
- you always know which file belongs to which package
- you can verify checksums of all installed files
- dependencies is not a problem - it's a solution to the problem
- it's simple to locate needed package from distro
- if you're trying to install someone else package, you'll better to get sources, and build rpm package youself
- I agree that it is bad idea to distribute rpm binaries only, so best is to post tar.gz source, rpm packages are optional (it is good if source includes .spec file)
- and if you don't like dependencies, you can always use --nodeps :)

P.S. When I start using linux in 1995, first distribution I installed was Slackware, and after one year I switched to RedHat.
Slackware is a good, but you have same dependency problems (and you even don't know which package to install in case of such problem, lets say then installing some binary package). It also much harder to upgrade it....

Many Errors

[harlows_monkeys]

The article is riddled with errors. Here are the ones I found in the first pass.

Section 1 complains about failed dependencies when installing binary packages. Failed dependencies are a problem with any packaging system (or source distribution, for that matter) that does not include everything in the package.

Section 3, claims that RPM creates fragmentation between distributions. No evidence is offered. The author appears to be making the mistake of assuming that since several distributions that use RPM are different, RPM must be the cause.

Section 3.1, claims that upgrading is not supported with RPM, but is with DEB. This will come as a great surprise to the hundreds of thousands of Linux users who regular update everything, including kernels, via RPM. Not fully sure how the author got this part so wrong, but I think part of it is that Debian is not commercial, so when they say something is "supported", that means something different than when, say, Red Hat says it.

Section 3.2, complaining about different versions of RPM causing problems. Changes quote about why Beehive doesn't use RPM or DEB to just talk about RPM. Greatly exaggerates the problems that were caused by the one time RPM underwent a change that was not backward compatible. Again attributes to RPM along problems that every packaging system has.

Section 3.3. Continues blaming RPM for the differences between distributions.

It basically continues on that way, making these same mistakes over and over, so I'll stop now.

Compared to Windows. . . .

[Com2Kid]

On Windows2k+, given a trusted vendor, I can click on a web link, click I agree, and a few minutes later have a new piece of software setup and all dependencies configured and taken care of for me.

The *nixs still have problems agreeing on a standard path format. . . .

(though granted MS's solution to this matter is not quite so. . . nice. Heh. They just support all of the different oddball paths ever used. :) Thus the prevalence of a C:\windows directory on NT installs, heh, sooner or latter some application starts installing crud to there. :) )

Re:Compared to Windows. . . .

[Com2Kid]

Right, but it's not that hard to conform to all distros if 'all' means 'one' :-)

You kidding?

C:\Windows\Games

C:\DOS\Games

C:\Games

C:\Program Files\Games

C:\Program\Games

C:\\Games

or for shared libraries

C:\Program files\

C:\program files\Common Files

C:\Winnt\System32

C:\Winnt

C:\Windows

C:\Windows\system

C:\Windows\System32

C:\Winnt\System

and likely a few that I have forgotten about.

Heck, IE stores temporary files in something like 3 different locations, and it is a bundled application! Some other applications commit far worse horrors then that (such as using the root directory for temp files. . . . ::shivers:: )

The fact that -anything- works at all is a minor miracle, that it works well enough for stuff to get done. . . . amazing. ^_^

We don't need no stinkin' package manager

[shoppa]

IMHO while package managers do have some use, they are only for the newbies who don't know how to build software from source. On any recent PC-clone most packages configure and build in seconds (OK, it takes more than a couple minutes to build the gcc suite or glibc from source on a Pentium IV, but not much more!), and you don't have to deal with the pain of needing specific shared library versions or pathnames that don't mesh with your own.

Package managers are intrinsically against what Linux is all about: putting control in the hands of the little guy. Building everything from source is how you get (and stay) in control.

Re:There is nothing wrong with RPMs. Only packager

[mattdm]

Actually, rpms can depend on files and/or packages. Either way.

But as for switching RPM-based distros to dpkg: RPM doesn't map 1-1 with dpkg. I don't want to get into a big relgious war (although, that's pretty much this whole story...), but one thing I find technically superior is the ease with which an RPM can incorporate multiple sources and multiple patches -- this means it's very easy to take a Red Hat package, which contains pristine, original source + patches, and add my own local patches leaving the RH patches in their own "pristine" state. This is harder to do in dpkg -- requires some slight-of-hand at least.

Re:There is nothing wrong with RPMs. Only packager

[Webmonger]

Yeah, I thought the "Red Hat .deb" idea was probably farfetched. It's nice to know that .rpm does have technical merits-- makes it easier to understand why distros and the LSB continue to use it.

What we need is a binary autoconf

[mark-t]

What if, when you wanted to perform a binary installation, it checked dependancies the same way that autoconf-like programs do... tries to find them in particular locations, and creates a configuration file for that program based on what it found? It can do version checking as well, and report any mismatches to the user. In situations where there isn't a clear-cut place to put such a file, the installer could create a bourne shell startup script instead. It would work everywhere, and wouldn't be dependant on _any_ rpm or deb databases.

I realize that this would require one new file (either a config file stored in the program's library directory, or a shell script used for startup), for each package that gets installed, but we're already looking at wasting space with the rpm or deb databases anyways.... this solution wouldn't take up any more space and has the added bonus of being completely cross-distribution!

For library packages, it shouldn't even need to store a config file... it can just check the versions of the software or libraries that it does require and report back to you. The job of actually finding the libraries as they are needed can be performed by the linker, which is presumably set up to search applicable directories. Heck, if it's not, even this information could be reported at installation time too!

everything you know is wrong.

[MSG]

Wow... This is one of the most factually flawed and misinformed articles I've read in a long damn time. And right after I woke up... I've got to find better ways to start my day.

Some of my bigger complaints:

...The installation fails, reporting a missing dependent package without which it will not install or function correctly.

LISTEN to what it's telling you. This is always the first complaint about rpm from those who don't like it. However, getting rid of dependency information DOESN'T GET RID OF DEPENDENCIES. Without the information before install, and without those checks, the software won't function after its installed. That information is absolutely critical when software has to continue functioning.

Upgrading an RPM-based distribution is risky at best

Based on what? Have you ever had a major failure? The only problems I'm aware of stem from replacing vendor packages with third party packages, which may not match the layout of the originals (or the new vendor packages.)

it has created enormous fragmentation between distributions

Nothing has created fragmentation but their own opinions about where things belong. Source distribution doesn't solve that.

developers are forced to take this fragmentation into account when creating binary packages

No we don't. Autoconf/automake follow the FHS for installation, and that's what most of us use.

with Debian, you only ever install once; upgrades are not only fully supported, but strongly encouraged.

That's not a result of dpkg, it's a result of apt. Apt is some bad-ass software, and I rejoice that it's now available for rpm. I've used it to upgrade a number of Red Hat Linux 7.2 systems to 7.3, and even upgraded one RHL 6.0 system to 7.3.

Not long ago, an RPM would work, period. The only possible concern was whether it was built against libc5 or glibc. -- Dennis Powell

Not long ago, GNU/Linux systems didn't provide many *useful* libraries for programmers to work with. libc as the basic dependency meant that developers had to impliment their own basic needs over and over again, which is one of the reasons that UNIX has not been a popular development platform in many areas.

Many of you will have remembered that the RPM Package Manager went from 3.x to 4.x without backward compatibility

Um... no. rpm went from v3 to v4 and it was backward compatible. rpm v4 could install all of rpm v3's packages. rpm 3.0.5 was also introduced, which could handle rpm v4 binary packages.

I just don't see how the distributions are going to bend over to offer concessions to each other.

Um... are you TOTALLY ignoring United Linux and the LSB? Both of these are multi-vendor efforts to standardize the basic system on which GNU/Linux distributions are built.

My own conclusion: If you have problems with dependencies, then the package was not built for your platform. There is, however, a meeting point between source installs and the benefits of rpm: The source rpm. If your binary rpm was built for some other platform, get the .src.rpm instead and build that. It's easy:
rpm --rebuild package-version.src.rpm

Re:Why the fuck we have to drag around libraries??

[An Onerous Coward]

Nice reverse psychology. Lacking a valid point, you threw in a bunch of distracting f-bombs in the hopes that everyone would assume that, underneath this inciteful harangue, you might be saying something meaningful. Fact is, you're not.

You're asserting that, because we all have broadband connections and 80 gig HDDs, there's no excuse for relying on an external package. This is a complete fallacy. There are still plenty of folks out there who are still downloading over 56K connections. They probably still outnumber broadband. There are also lots of people still using small (10G) disks. But even if everyone is running the latest and greatest, there's no reason to throw away HDD space, system memory, and downloading time by having a dozen copies of one library.

Also, as an earlier response pointed out, library systems make it easy to fix exploits. It's much easier to simply update something like the zlib package than to wait for a new version of every piece of software that uses it, and then download it. The former should be fixed within days and requires a 500K download. The latter could take months and require gigabytes.

I'll admit that the library system isn't perfect. Library developers don't always maintain backward compatability. Application developers take the easy way out by requiring "version 1.1.4b" of a library when any 1.x would have worked fine.* But your "solution" carries its own non-trivial problems which you don't seem to recognize. Or maybe you're just a troll.

* If it really does require 1.1.4b, then by all means, include it in the application.

Re:There is nothing wrong with RPMs. Only packager

[Webmonger]

Yes, I've been corrected on this already-- file dependencies are not the only option. It does look like the mere existance of file dependencies is problematic, though.

Re:standardized Linux configuration files...

[jcast]

I think the suggestion was to make a standardised GUI. Those who want to use vi, emacs, whatever still could, and the basic system would still work. Newbies, on the other hand, can use a cleaned-up interface, which I predict would spread across all Un*x variants if done right. After all, isn't the point of slowly-evolving that you're never done, never perfect?

Re:There is nothing wrong with RPMs. Only packager

[Tester]

Another important problem is that last time I checked Deb could not be signed, while all RedHat RPMS at least are PGP signed. The last time I heard about that on debian, they couldnt agree on a way to make signing meaningful... RH signs all its packages with one key, but that would be hard for deb...

Re:Talk about a gimmick

[dattaway]

Configuring how packages are compiled in gentoo can be set with the USE environment variable, or editing it in /etc/make.profile/make.defaults. There are many useful options that can be set there.

Compiling is done with the "emerge" command for that package. Just for grins if you want to reconfigure *everything* with a new set of interesting compile parameters, simply type:

emerge world

And watch the CPU happily crunch away on every line of code that is currently installed on your system!

"emerge rsync" updates the packaging tree. Then you can update packages, system, or the world with the -u option.

Re:There is nothing wrong with RPMs. Only packager

[AME]

.rpm archives depend on specific files, while .debs depend on specific packages.

You say that as if RPM can do dependency based on files only. This is not true. RPM can also do dependency based on "capabilities" which are provided by other packages. Observe the "-q --provides" option. The choice of depending on files or capabilities or both is up to the packager.

I hope so

[josepha48]

I have actually started using NetBSD and really like there package management. make, make install, make uninstall. It will pick all the dependancies as well, and you have the option of uninstalling all the dependancies as well. I think using this on Linux may be good. It also does binary packages. I think debians apt-get is like this.

I would love to d a redhat like distro only removing rpm and putting in the BSD package management system. But I don't have the time right now. Maybe I'llopen a project up at sourceforge.net.....

Re:There is nothing wrong with RPMs. Only packager

[kigrwik]

> APT is what makes debian's package management so
> smart, not dpkg.

Sorry, but you've got it backwards there.

"APT makes Debian's package management so easy to use."

But what makes it smart is the Debian Policy that states exactly how packages should behave, not the "Guidelines". The difference is that not conforming to Policy is a "Serious" bug (read: Release-Critical) , whereas guidelines do not convey the same sense of absolute necessity. :)

As the old chinese proverb goes:
"When the wise points at the Policy, the fool watches apt-get"

Note that most Debian developers are not paid to work on their packages, they do it on their free time, so your comparison with RPM packagers might not hold 100%. The one tool that truly helps is the bug tracking system, (http://bugs.debian.org) and the great number of users that provide bug reports and patches.

The culture you're referring to is a strong driving force in striving to achieve excellence.

Consider this a corrective patch to your original post with which I [almost :)] fully agree.

Re:There is nothing wrong with RPMs. Only packager

[Anomie-ous Cow-ard]

this means it's very easy to take a Red Hat package, which contains pristine, original source + patches, and add my own local patches leaving the RH patches in their own "pristine" state. This is harder to do in dpkg -- requires some slight-of-hand at least.

I don't remember needing any slight of hand to do this. apt-get source foo, gets the pristime source and the patches. Copy the patched source dir, make my changes, and diff against the original patched source dir. There i go. Later, get the upgraded version (apt-get source foo automatically only downloads the new diffs, using the old upstream sources (unless, of course, it's a new upstream version)), apply the patch, and there i go again.

If you don't want to use apt-get, download the .tar.gz, .diff.gz, and .dsc files by hand and dpkg-source the .dsc to have it unpack for you. Or do it by hand with standard tools, you'll just have to remember to chmod +x debian/rules that way.

I'm having a great deal of trouble seeing your technical superiority here. The only possibility i see here is if rpm would automatically try to apply my patch after applying the distro's patches, which likely as not is going to fail anyway. Please explain.

no no no

[Ender Ryan]

You are confused, the registry can easily become corrupted causing the system to be unbootable, that's one terrible single point of failure.

/etc is composed of many different files, the ones essential for bootup rarely, if ever, need to be modified, so it's extremely difficult for any type of crash to cause the system to be unbootable.

Re:no no no

[sg_oneill]

-Yes. But despite that, the breadth of etc's *multiple* points of failure mean that factually there is a higher probability for a gooned bootup.

Contemplate.... Manually edit a passwd file & blow the first line... OoopS no root login , again, ever.
Punk out inittab ... no start up services.
fstab .. your nfs kernel modules go awol..

ever seen what happens when you make a passwd file to big on an axis uclinux+jffs box? passwd file dies as fs mysteriously grows terrabytes in size.. No boot. thow away embeded box...

I could go on. I agree that the registery is a highly nukeable thing, but it's singular.

Re:There is nothing wrong with RPMs. Only packager

[Ed Avis]

Absolutely. The points raised in the article have _nothing_ to do with the choice of RPM as package format.

Point one: dependency hell. When you install a binary package it requires several updated libraries, each of which may require other upgrades... well yes, of course, if it's built against a particular library version then it may require those versions. At least with RPM and other packaging tools you get a warning about what is required. Don't shoot the messenger.

The comparison with Debian: it's just because Debian put lots of effort into upgradability, and most RPM-based distros don't worry about it to quite the same extent. Talk to someone who started with Corel Linux and wanted to update some packages, and you'll see that the choice of RPM vs dpkg vs whatever doesn't matter here. Just the quality of the packages themselves.

RPMs being awkward because files are in different locations: any binary package will have these exact same problems, as long as distributions use differing conventions. This is just the familiar complaint about there not being a single Linux standard which all distros follow.

Then the author goes on to talk about using apt-rpm or Debian, totally missing the point. The reason these tools work so well is a good *collection of packages* put together by the maintainers of those distributions. It's not related much to package formats, beyond some really basic dependencies. The 'switch to Slackware' arguement is similar: Slackware's more upgradable because the packages themselves use the same conventions from one release to the next, not because .tgz is magically superior to .rpm. In a parallel universe where Slackware used RPMs and RedHat used tarballs, the argument 'switch to Slackware' would be just the same.

As far as I can tell, the Distrowatch article is just complaining that it's not always possible to pull random binary packages off the net, install them on your system, and expect them to interoperate with other random binary packages built by other people. Well, duh.

Re:Not on all mirrors

[Decimal]

Not all mirrors have this notice. So the mirror you visited needs an update.

Would Slashdotting count as an update? :)

What RPM should really do...

[Zenki]

Is offer an interactive mode of execution.

When installing a package, if RPM can not find the RPM dependency, it should tell the user:

"Unable to find libfoo.x.y.z.so"

Then ask:

"If you do have libfoo.x.y.z.so, enter the path so an appropriate entry can be made in the rpm database"

The user can then type in something like /usr/local/lib/libfoo.x.y.z.so, and the RPM program will add that one file into its package database so later on, it won't have to ask that dumb question again.

If the user doesn't type in anything, then RPM should then quit and refuse to install the package.

kernel at -O3?

[zenyu]

You're playing with fire mister.

PS in case I want to try this what exact kernel version did you use?

Re:kernel at -O3?

[jred]

Could you perhaps elaborate a bit for those of us who don't have all the params memorized? Why is it bad?

Thanks

Re:kernel at -O3?

[zenyu]

Could you perhaps elaborate a bit for those of us who don't have all the params memorized? Why is it bad?

-O0 -- no optimization, good for debugging
-O1 -- some optimization, usually safe even when you've got something that should be volatile but isn't.
-O2 -- well optimized, but meaning of code never changed.
-O3 -- most optimized, code you wrote is probably not the code running. May cause core dump, may write over memory randomly, hopefully just gives wacky floating point results. Also may run slower, due to code bloat.

-Os -- chooses smaller constructs whether they are faster or not. Sometimes produces faster code, sometimes not. Probably safe.

-O3 is very unsafe from my experience with 2.?? gcc compilers. When it's your own code you can usually massage it to work, but for something like the kernel, I'd turn it on on one source file at a time, stress test, and send in any patches needed to get it working. It has always been recommended that you compile the kernel at -O2 or less. I hope that most developers test with -O3, just because it might reveal a bug that'll show up with a later compiler, but I wouldn't bet on it that they all do.

Re:kernel at -O3?

[EricLivingston]

Checking the man page, O3 does everything O2 does, but also adds inline functions, which means the compiler has the option, instead of encoding a call to a function (as normal), of actually just plopping the function's code down instead of the call, thereby eliminating the overhead of making the call in the first place. I'm not sure what drives the decision - back when I was using Borland C++ you could use the "inline" modifier on a function to tell the compiler to do that, for instance if you wrote a "write_pixel" function or something that gets called an insane amount and is extremely small.

I completely agree, by the way, that it's dangerous to play with -O3, and I've had to back off to -O2 on several packages that just fail when I've tried -O3. Since the box in question is not my server, I take greater risks...

Re:There is nothing wrong with RPMs. Only packager

[RollingThunder]

It definately covers how to do this in Maximum RPM, which is on rpm.org.

http://www.rpm.org/max-rpm/

Re:Why the fuck we have to drag around libraries??

[Pig Hogger]

You just made it up without thinking about, don't you?
You are talking about static linking for everything - it could work until some point. One of the points is disk capacity - when instead couple kilobytes for simple program you'll have couple megabytes, and instead couple megabytes for complex program you'll have couple hundred megabytes...

I thought it very carefully, after working many years supporting & fixing Unix, Windoze and Macintrash boxes.
Macintrashes have plenty of shortcomings for sure, but one of them isn't the library mess, c'oz the binaries carry everything they need with them.

On use of /opt

[Nailer]

rpm installs should use the opt directory for major programs. /usr/bin and /usr/X11R6/bin is not a dumping ground.

Er, yes they are. Unix has sorted files by their type, rather than what application they belong to, for a very long time. This allows, for example:

• All your applications to be in path
  
• Short ldconfig paths
  
• Someone to back up, say, only /var and /etc and get everything they need to restore your system (because the binaries are reloaded from media)
  
• And a great deal more.
  

If you want to address the files by what application they belong to, that's what a package manager is for. No distribution's packages can use /opt, doing so is forbidden by the FHS.

Re:On use of /opt

[BrookHarty]

FHS says to use /opt for add-in software, then use it for that purpose. Most install packages can alter your ldconfig and add its path, check KDE and Gnome, they do. I dont know what the Great deal more is, but kde, gnome, open office, kde office, are too big (imho) to be put in the same damn dir of /usr/X11R6/bin.

Mozilla is in /usr/lib/mozilla, /opt/mozilla would make more sense. Lucky its an easy fix, and its no harder to use.

Its pretty easy to modify your profile path, ldconfig, and make a simple standard, like anything not unix OS goes into /opt.

Using 1 directory for all your bins is a cluster fuck.

Re:On use of /opt

[Nailer]

FHS says to use /opt for add-in software

Cool. All you have to do is define what add on application software means...good luck.

The FHS also says The directories /opt/bin, /opt/doc, /opt/include, /opt / nfo, /opt/lib, and /opt/man are reserved for local system administrator use...distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator. I.e, distributions should avoid /opt and leave it to the local system administrator.

Mozilla should puts its bins in /usr/bin, its lib in /usr/lib, and everything else in /usr/share.

Using 1 directory for all your bins is Unix

Re:On use of /opt

[BrookHarty]

Guess you havnt checked out mozilla lately, its entire directory is /usr/lib/mozilla, the program mozilla in /usr/bin/mozilla is a shell script that loads /usr/lib/mozilla-bin. You can download the mozilla tar, and extract it in /usr/lib/ and you dont have to change anything.
Why couldnt we do the same thing in /opt, like some packages use /usr/local. (like kde, and many other apps)

BTW, when your using a linux box as a workstation,
IE. you are the local administrator, and should be able to do what you want. Using 1 directory for all your bins is not Unix, this is why you have /opt and /usr/local/bin /usr/local/sbin, /var/adm, blah the list goes on.

The point is, if you use single directories for applications, you can back the directory up, and install new software without touching system files. Why would anyone sane put system files in with application files? Microsoft have "Program Files", unix should use /opt or /usr/local.

Using the phrase "Its the normal way" is just rehasing the same mistakes. Improve...

Re:On use of /opt

[Nailer]

Guess you havnt checked out mozilla lately

Yes I have - I mentioned it as an example of a noncompliant application. Mozilla, as packaged by most distribu
tions, violates the FHS. Anything which isn't a library or non-user executed binary does not belong in /usr/l
ib. Read hte FHS definition for /usr/lib. Hundreds of other apps correctly use /usr/share for this purpose.

BTW, when your using a linux box as a workstation,
IE. you are the local administrator

If you are using a Linux box as a workstation you aren't necessarily a system administrator, but anyway...

and should be able to do what you want

Why? This makes it unmaintable for whoever takes over your job / system.

this is why you have /opt and /usr/local/bin /usr/local/sbin, /var/adm, blah the list goes on

Read the FHS. The FHS sorts files by their importance, then by whether they are administrative in nature, and the
n by what kind of file they are. / is for programs necessary to recover the system /usr is for others. The sbin d
irectories are only for system administrator use, the bin directories aren't. /var/adm doesn't exist, because var
is for variable information- ,i.e that which changes frequently withlout system administrator information. Binar
ies don't belong in /var.

The point is, if you use single directories for applications, you can back the directory up, and install new s
oftware without touching system files.

You can already do this with a packaging system.

Why would anyone sane put system files in with application files?

If by system you mean required to repair the system (one common definition), this is already the case: see the FH
S definition of / versus /usr.

Microsoft have "Program Files", unix should use /opt or /usr/local.

Why? This limits what I can do. With the current system, I can

• back up /etc /home and /var and have everything that's unique about my system.
  
• Mount / read only, and /home and /var read write
  
• Keep all the apps I need for repairing my system in a small and centralized place, so I only need one filesys
  tem to repair my machine
  
• Keep all my applications in one short path
  
• Keep all my libraries in a short path
  

I agree heartily with the concept but in this case Unix has something which is massively superior. None of the be
nefits listed above would be avaliable, and you haven't shown any gain in your method. I can think of one though
: chrooting services would be easier. But asides from that I don't see any reason to change the current system an
d lose its many benefits.

Re:Gentoo is a giant step, too long for mere morta

[Wdomburg]

>Have you tried doing a minimal install, with ssh,
>but without X?
>
>Actually - I'm kinda bluffing that it won't work
>here, it didn't work on SuSE so I'm assuming it
>won't work on RH either.

Works just fine. Just because two distributions are rpm based doesn't mean they make the same mistakes.

Actually, the only thing that Red Hat makes you install is the "base" package list. Comes to maybe 200MB and contains, IMHO, very little crack rock. About the only things I might be inclined to strip out are slocate (not exactly a good thing on high volume servers with millions of files), gpm and mouseconfig (sixty servers, no mice).

Don't take this as a personal affront, but it constantly amazes me how ungrounded in reality many people's complaints against Red Hat are; e.g. they turn every service on by default, they don't test their software before shipping it, their minimum install is bloated (feel free to take offense at that, if you must), they're not striving for LSB compliance, etc, etc.

There may be some cases where they were guilty in the past, but they've done a more than adequate job of responding to issues when they crop up and are, IMHO, one of the better distributions out there.

Matt

Re:There is nothing wrong with RPMs. Only packager

[Nailer]

I have never heard any argument that .rpms have a technical superiority to .debs

I have. You just hear these arguments less because, in my experience, there's honestly more Debian people who seem to want to bash people over their head for their choice of distribution.

• RPMs verification options are much more powerful (they provide more information about what's changed) than Debsums, which doesn't even exist at all in the stable Debian release.
  
• RPM's database, DB3, has transaction capabilities that make it a little more robust
  
• Various non-technical arguments which are important but not to do with file formats: signing Deb's to particular people is great, now what do you do when they trojan their package. Fire them? Again, this doesn't matter to the file format, but because Debian folk keep throwing policy (which can and does exist for RPM based Linux distro's) I thought I'd throw it in.
  

so I have to wonder: why don't RPM-based distros don't switch to deb?

• Because they both have areas where they are superior to each other
  
• Because RPM has a massive user base and Dpkg doesn't. It would be a long undertaking to do this for little benefit (see below)
  
• Because having a package depend on what an application does is logical. Apt-get works fine with this - I run a repository for Red Hat 7.3 at work.
  
• Because policy is nontechnical and easy to implement on RPM based distros
  
• Because up2date, apt-get, urpmi, and various other front ends do for rpm what apt-get does for dpkg.
  
• Because its probably easier to add the few things which are better about dpkg - suggested / recommended dependencies, and either of dependencies (FTP Server OR Web Server) than to move most distros from RPM to Dpkg and then add the missing features of rpm to dpkg
  

Re:My Linux Expiriances...

[Wdomburg]

>Now it's true that Potato (aka Stable) is out of
>date. It's stable as hell, but I don't think any
>desktop user should use it (servers are another
>story, as is often the case). "Testing" has been
>just as stable for me as full releases of >Mandrake and others, that is no crashes. I've
>never used unstable, but hey, I've got a extra
>box lying around here somewhere.

Just to reiterate... SERVERS ARE ANOTHER STORY... I've seen a number of people saying that they keep the servers they admin up to date by putting an apt-get update in cron, and also that they use testing because it's "stable as other distributions".

But I've had serious issues on a home box that I upgraded with the testing branch in a futile quest for more up to date software; e.g.

sendmail was 'upgraded' to store its mail
spool in a different location, without any
clear notification, without moving the mailboxes
or putting in a symlink, without changing any
of the other mail programs to look there...

apache was 'upgraded' to a version that was
compiled with large file support, but didn't
have a dependcy on a kernel that could support
this so it would randomly crash...

for some ungodly reason it decided to install
z-mailer and wouldn't let me uninstall it even
though no packages depended directly on it or
on an mta at all (iirc it required deleting
a symlink somewhere on the system or something)

several of the packages are compiled such that
they are trying to use unimplemented syscalls
(likely compiled against a different variant
of the sun4 architecture than I have)

And those are only the issues that come to mind. I'm still pondering whether I want to give OpenBSD or NetBSD another try, but last I checked their NIS implementation was piss poor.

Matt

Total disagreement

[Niscenus]

The problem is not the filesystem. Only users uncertain about the FileSystem Hierarchy Standard or the basis of the POSIX layout could make that mistake. Once you start installing your own files, you'll find most of them goto /usr/local/share, which, for a Windows, is much the equivelant of C:/Program%20Files.

The problem with RPMs comes out of the libraries used by the individual compiler. The most noticeable of these is when an unsuspecting regular GNOME user tries to install a binary constructed by a Ximian GNOME user. Most often when you're told by your package management utility that the particular package has a dependency issue, over fifty percent of the time, I would bet, it's really complaining about a library someone else has that you don't, and the remainder is typically a particular application it was designed to use. If you installed from sources, you would see, and I'm saying from experience, around 85% of these problems dissipate. A large part of this in thanks to considerate programmers who put the time to write alternative configure lines for the to-be-abstracted make file.

If ./configure --option(s) && make && make install && make clean && rm -rf ../<name> is to difficult for you to do, perhaps you should consider using a Mac.


Ditto on make uninstall too, oh, and don't do the && rm -rf if you think you're going to use make uninstall.

For all other questions about POSIX, feel free to pickup this handy guide

For anyone else with actual standards questions, my email still works (just in case those of you who still care about standards, both of you, still want some guidance).

Upgrading RPM based distribtuions.

[guacamole]

I have upgraded various versions of RedHat in the past and in general the upgrade worked very smoothly. I am typing this on a box that was running 7.0 originally. Later it was upgraded to 7.1, then to 7.2, then to 7.3. The upgrades worked very smoothly. I have also upgraded production servers from 5.1 to 6.0, from 6.0 to 6.2, from 5.2 to 6.2, from 6.2 to 7.2, later this week I will upgrade one of our servers from 6.0 to 7.3 and, frankly, I quiet expect this upgrade to work. Yes, you have to be very careful, keep the backups around and make sure your disks are partitioned so that the latest version of RedHat will fit on them.

My $0.02

Fragmentation of Linux distributions is the problm

[guacamole]

The real reason it is such a pain to work with rpm
packages is that the distributions are so fragmented. You can't expect the packagers to build an rpm for five different versions of redhat, suse, and caldera and post that on his/her site. So, your milleage may vary. Possible solutions to this:

1. If possible, stick with a recent version of RedHat. Almost always you will find packages for it.

2. Use SRC rpm packages. Recently, I discovered that I can just rebuild the rpm package from source on my system with command "rpm --rebuild .*.SRC.rpm". So, if someone posted a binary package that works only on SuSE but you need to run it on RedHat, just get the source RPMs and rebuild them.

3. When trying to install something first look if your distribution already has a package for it. RedHat for example now comes on three CDs, that's quite a lot of packages there and all of them are guaranteed to work. You might also try to grab packages from the next version of your distribution but that might be tricky.

4. Finally, use the source Luke. I am tired about
all this whinning and packager wars in the Linux community. Do you know that on other operating systems (e.g. Solaris 7 and older) users have to compile by hand even the basic things like bash and ssh? But that's only after you get a gcc binary that works. Fortunately, with Solaris 9 they now bundle tons of freeware software, but still, lots of stuff will just have to be compiled by hand.

Another problem with the rpm packages are dependencies. This problem is much harder to solve and it is not specific to rpm only. Unless the packager has setup some sort of dependency list for apt-get or autoupdate (rpm) users then, you still have to make sure that you download all the required packages by hand and install them. Debian has avoided this problem mostly by packaging all cool software in the distribution. However, the extremely slow release cycle makes much of that very useless. For example, the current stable version of debian comes with openssh 1.x which does not support SSH protocol version 2 and the openssl version in Debian is so old that the latest version of openssh will not compile with it. So, you have to get a more recent version of openssl, and then install openssh. I know that there might be deb packages somewhere out there, but I just prefer to build the thing from source.

My $0.02

Re: The Mac Way

[reflective recursion]

Libraries are shared code, intended to be used by multiple programs/apps/packages.

Erm. People are hung up on this library thing. The reason we have */lib today is not a user or developer convenience. It is a linker convenience. All the linker has to do is scan a few directories in it's path. Perhaps another idea behind the */lib structure is all application libraries go into this directory and a developer can simply find and choose a library to use. In practice it is never like that. A developer uses a library which is pseudo-standard, such as GTK+, Qt, ncurses, Xlib, etc. Sometimes a package may create libraries which it uses itself, such as The Gimp. The Gimp uses libgimp for plug-ins. The thing is this: The Gimp and libgimp go hand-in-hand and it would be very difficult seperating the two. It makes no sense to seperate the library from the binary and have people confused as to which version is on their system. If you simply had a directory called "gimp-1.2.3" then you would know exactly which version. You could also depend on that package and be guaranteed that it would never change.

Another issue that goes along with libraries is where do applications place their header files? I have had major issues with this. Typically, what happens is old header files get mixed with new header files and when you go to compile an application it will many times get confused (include wrong files, etc.). If libraries had their own seperate directory, then you could place all header files there too. Imagine how much developer time this would save. I don't know if you use GTK+ or GNOME style libs much, but they have scripts written just so developers can link to the library easier (gtk-config, *-config). Type "gtk-config" at the command line to see what I'm talking about.. I'm sure you have it. Imagine how simplified linking to an application could become. Instead of needless -I and -L we could just do something like: --usepackage gtk+-1.2 and the linker/compiler would know exactly what needs done.

This is a serious problem. Think about why KDE and other medium to large applications are using /opt today. IIRC, Slackware installed GNOME and KDE both in /opt. Look in there and you will find exactly the same structure as your file system. Now you end up adding another path to $PATH anyways. What about X? It has been doing basically whatever it feels like with its libraries and includes. Typically they fall into /usr/X11/*. IMO, the only possible solution is a major overhaul. Package management that we use today doesn't work at all because any modification to the file system could wreck dependency havoc. For example: if I removed gtk-config, I just killed the library. Yes, the library file is there and works for existing libraries. If I ever need to compile something with it though, I'm out of luck.

I'd really like to get my hands on a Mac w/ OS X. It sounds really cool and I've heard many good things about it...

Re:Something obvious

[Veteran]

That is absolutely true - I don't have a right to bitch about anything I can do something about - neither does anyone else, and I don't bitch about things like medical care - period.

The article was a series of complaints about the design and implementation of an open source piece of code. My point is that unless you are a coder you don't have any business complaining about it.

I am an open source coder - I have contributed several thousand lines of GPL software; that contribution gives me a right to say something on the subject. If you haven't written open source code - and the author of this article evidently hasn't - you don't have any right to be critical.

People seem to think that they have a right to be critical of anything at anytime, they don't, and it is time they were told so.

Children function by attempting to manipulate adults - since children have nothing and adults do - they try to be clever and get things from the adults who have earned them. We as adults know this, and I did it when I was young - but not for very long. Maturity cones when you quit trying to manipulate people and start earning your own way.

By the way - coding around a problem is the way to get people to accept your solution.

To the clueless moderator who marked my original post 'flamebait' - that was not an attempt to draw flames - that was a lecture for a bunch of people who need to think about what they are doing.

I don't want to hear one word from anyone who isn't an open source contributor - your opinions on the subject are of zero value to anyone.

What about BSD?

[The Raven]

I have used NetBSD on servers, and was highly impressed with the ease of installing via their source based distro tree (pkgsrc). No comments I have seen have discussed it or compared it to the Linux solutions. Could someone contrast and compare, for my edification at least?

Re:Install redhat in 2 minutes.. hahaha

[MSG]

I'm sorry. You're right. I wrote that right after I woke up. It takes all of two minutes to transfer the files over HTTP and unpack them.

The whole process takes just under five minutes. My own interaction is only needed for 20 seconds, however; I have to pull the floppy after the machine stops reading it.

Link on local machine...

[arsaspe]

I gave up using RPMs long ago because of the dependancy problems, and nowadays always compile from source. I find this generally causes a lot less problems. The only gripe I have is that large programs can take hours to compile.

My proposal is to distribute semi-compiled packages. The Distributor (i.e. Redhat) compiles the program on there machines as per normal, except they dont link it. They distribute a package containing .o files, and a makefile. Installing the package does the final step in compilation- linking the object files.

This would solve most dependancy problems. If I have a different version of a library with rpms, the program generally wont run. However if you you do the linking locally, the program is linked to your libs as if you compiled it yourself.

It also solves the time problem. Large packages would take no more than 20 seconds to link.

If you came up with a packaging system like this, and make it a little more flexible (Allow the user to choose install dir!!!!!), then you have a fast installation that works on pretty much any system.

This doesn't go anywhere near far enough

[lamontg]

I wrote up a rant about this subject the last time I was unemployed: http://www.scriptkiddie.org/rants/registry.html.

The executive summary is that there needs to be a better designed tool in between the software developer of the package and the system admin who installs it. I would like to have the flexibility to setup a policy on my machine as to weither or not I'm using /usr/local/bin or /usr/bin or /packages/whatever/bin, etc. And then have the installer configure the package correctly to install it however i'd like.

One thing this would necessitate is making the installer be much less flexible to the developer than RPMs. The problem with RPMs is that they're way too flexible for the developer of the package. There needs to be a simple, inflexible API or else you're going to have a mess.

I titled it "why unix needs a registry?" just to throw some gasoline on the fire... Read it and see what I really mean (unix needs a centrally-accessable database of metadata about installed programs...)

Re:Windows has us on this one.

[simm_s]

A linux registry is a good idea and technically possible. The only problem is reality. Create your distribution with the linux registry and guess what? You have just now compounded the linux packaging problem by adding another incompatible package format. One must create a package does not need a package manager and has the functionality of a package manager.

It's about time

[rifter]

It's about time someone called bullshit on rpm. One of the interesting points in the article was that not all packages are created equal, thus you must find a package that works for your version of rpm, your distro, and the version of your distro you are using. However, I have found that even using rpm's from the install cd of the next version of an rpm distro will not mean the install will go through smoothly.

I'm not just talking about normally failed dependencies; that is understandable enough and can be dealt with (though the author was more than generous in his treatment of the goose chase that can be) but in fact I am talking about a situation in which you have libfoo-mdk-8.0-5.5.1 and are trying to install the rpm for libfoo-mdk-8.1-5.6.4 and it chokes, saying it requires libfoo-5.5.1 installed, or something to that effect.

When you can't even use rpms from the next version of a distro to upgrade your distro, there is a problem. Hell, even microsoft had that much working long ago. Why is the answer to getting to a new version of a distro often a fresh install? For that matter, why do many distros in their faqs for setting things up only tell how to do it in the install, as though no one is ever going to change things later?

Which of course is why I use slackware. The system is clean and relatively free of proprietary extensions to the way things are done. Most things are configurable on a slackware box in the same way most other unix boxes are. And I don't have to deal with rpm's. At first I used the slackware package system a lot, but lately I just compile most stuff from source.

Of course, this does not deal with a major cause of rpm dependency hell, which is the extremely fragmented nature of linux projects. Granted, this is building off the unix tradition of using mamny small parts to come together to a cohesive solution. However, it becomes a problem in two areas: one being the desktop user, and two being complex applications that require many of these parts. Usually the two are involved together, as with a project like Enlightenment or KDE. The problem is that when you want to install one thing, it requires 30 others. But you have to figure out where they are. Now I can do that, though it can be a headache, but what about poor Joe Sixpack and his shiny new Walmart computer with Lindows and DeerHunter installed?

In desktop systems like BeOS, OS/2, Windows, or MacOS, it is typical to encounter everything needed to run the program packaged with the program, right down to system libraries. What Windows based game written in the last 6 years did not come with some version of DirectX right on the cd? Now, granted, the windows way screwed many over, as program installers installed older libraries over newer ones and wreaked other fun havok on people's systems, and microsoft's patches gleefully broke people's programs. But, still, if we are talking about getting linux on the desktop, we shoudl be talking about learning from microsoft's mistakes and coming up with something better.

I think it helps everyone to have better package management, and definitely better dependency handling. I think apt-get and sourcerer's "spells" might be steps in the right direction, but I'm not ready to call it there yet. Oh, and I am sure lots of responses to this article will say it should be tough for newbies. But what we tend to forget, is that there really is not anything wrong with things being easier to do. In fact, saving time and trouble is supposed to be what technology is about, and putting a better tool in a skilled hand is the best thing we can do. The only problem is when we obscure the works so much that it is difficult or impossible for that skilled hand to fix the tool should it go awry, and this is of course the case with both windows and rpm, which is why I use neither if I can help it.

Excuse me while I die crying.

[Doktor Memory]

The syntax of UNIX config files is pretty standard

It is? Please enlighten me: which standard would that be, exactly? The one used by /etc/hosts? Yeah, that looks pretty much like the one used by syslog.conf, except oops you can't use spaces in the latter, it has to be tabs. Of course neither of them look much like Apache's config files, which in turn bear no resemblance at all to SAMBA's. Oh, and let's not forget what happens if you're silly enough to leave a blank line or a comment somewhere in /etc/passwd.

The /etc directory on a newly installed RedHat or Solaris machine contains close to a hundred files, and damn near each of them has its own unique configuration syntax, many of which will cause total failure if you use it in the wrong file.

The sense of accomplishment that unix geeks get from knowing how to manage this 50-car-pileup of interfaces somehow usually manages to overwhelm what should be our righteous indignation at being asked to do such a stupid thing in the first place.

You can rag on Microsoft's design choices all you like, but at least they actually attempted to solve the problem. Hell, at least they realized that there was a problem. Throwing your hands in the air and saying "let each app pick its own way" increases your job security at the cost of decreasing the likelihood that unix will win the datacenter wars.

Re:LSB idea type thing

[jilles]

Than the next obvious question would be which file system structure. Which immediately poses the question what distribution to standardize on which in turn makes it very clear that the first is infeasible.

The problem (depending on your point of view) with OSS is that you cannot require developers to work in a certain way. Attempting to do so usually results in flamewars. OSS projects exist because the members don't like similar OSS projects and decide to do things their way.

Re:Talk about a gimmick

[EricLivingston]

Sure, but the point of Gentoo is you don't have to think about individual packages. If you want to add system-wide support for a certain library or security framework or something, you simply add that option to your "USE" variable in your system's configuration, and every single package on your system that can make use of said library, etc, is automatically compiled with that feature turned on. You do have to set it prior to building your system for best results, however. Unfortunately, Gentoo still does not have the option of re-setting your USE variable, then issuing the equivalent of "recompile everything that is impacted by these changed configuration options". That would be very nice. On the other hand, you can issue an "emerge world" command before going to bed and have Gentoo recompile your entire system with your new options.

The reverse is true, of course, if you want to disable it system-wide.

Re:Gentoo is a giant step, too long for mere morta

[Wdomburg]

Actually, the X forwarding stuff isn't a compile time option. It won't work unless you have X installed, of course, but it doesn't break it if you don't.

The packages that have options that would cause dependencies (e.g. emacs with X11 support) are in fact often split into different pacakges - emacs-nox and emacs-X11, vim-common/enhanced and vim-X11. Other ones take advantage of software that has modules, such as apache and perl. And a large number of other packages are compiled with optional features enabled, but not turned on in the config files.

Big dependencies (e.g. X, Python, Perl) *are* seperated out into their own packages, and in most cases other features are turned on by default. And once you start looking at desktop level software, configuration is usually done within the application, not compile time. But even when that's not the case, it is often provided with plugins its easy to package on their own (look at GStreamer, the multimedia framework - each codec that has an external dependancy is split out into a seperate RPM so you can install only those features that you actually need).

My main point is that most people *don't* do customization on their software. Remember, the mantra of source code advocates is "but compiling is easy, it's just ./configure && make && make install!".

I can see the appeal of something that automatically configures itself based on what you have installed, even if I see it being of limited utility. And I can see some issues with it, such as the gentleman who pointed out that in Gentoo, if you compile with a library installed, then remove that library, it will silently break the application.

As for difficulty in custom compiling RPMS, it's really not nearly as difficult as people make it out to be. On a lot of packages, if you do a rpm --rebuild on a SRPM, it runs through a straight configure that detects what libraries are installed, and the find-requires script will write your new RPM with all the proper dependencies.

And if you need to change an implicitely specified option, you can install the source rpm, change the "./configure" line in the spec file, and rpm -ba it.

But most of the time this really doesn't buy you much. I run about 60 Red Hat machines and the only custom RPMs we need is software that was written or modified in house, and the kernel, since there was a particular issue that we needed to patch away (a two line change to the spec file).

Matt

Re:Why the fuck we have to drag around libraries??

[Pig Hogger]

Libraries are the biggest stupidity since Windoze.

It's just as st000p1d as the DLL crap with Windoze. You might have an excuse with proprietary software that's kit-bashed from different sources or of which you may want to update or patch a "feature", but with software of which you have the source, there is NO EXCUSE for that dependency crap.

At least, that's one thing most Macintrash programs have right: no goddam fucking library/DLL dependencies. Everything is in one binary file!

With the big disks we have nowadays and the high bandwidth, there is no reason why you should not be able to include the whole fucking shebang with the application, and keep it isolated (to prevent it from breaking other programs) on your system while you compile it.

(Reposted, account being moderated into oblivion)

your theory != practice

[Ender Ryan]

In theory, in your head at least, you are correct. However, in practice, the windows registry gets fucked up enough to render a system unbootable far more easily than /etc.

The problem with the registry is that it is a single point of failure that is also prone to failure. /etc is not prone to failure at all. Making trivial system changes, non-trivial meaning altering something not part of the boot sequence, can't fuck up your system that badly. With the registry, a simple crash or power failure can toast your system.

Further, your "multiple points of failure" line is complete bullshit. The files in /etc, being multiple files, isn't in any way meaningful at all, except modifying one can't corrupt another, so you're actually completely backasswards in your logic.

Great! I will try it.

[Futurepower(R)]

Great! I will try it. I didn't know it existed.