OSNews

Alright, good point. So how about instead of having every distro install files in the same place, as part of the standard, we have each package manager have a file called 'paths.xml' (or something similar) that would describe to other package managers exactly where the files and directories on a particular distro are kept? IMHO, the user should have the option to be able to choose exactly where they want to install the stuff anyway. So when an app is installed, the package manager keeps a log of exactly where it is, how it is installed, and which compile-time options are enabled.

That would require a lot of change, but would be a great solution. A lot of software tends to rely on absolute paths, i.e. /etc/configfile, instead of $SYSCONFDIR/configfile. You can change this usually with a configure script, but once the software has been built, there isn't much changing.

Even relocatable packages, i.e. 'soft' path, wouldn't be able to do this. Say the config file is found in $BINDIR/../../etc/configfile. Or the library in $BINDIR/../lib. Basically, if one distro puts their libs in /usr/lib, and another in /usr/share/lib, then changing LIBDIR (which doesn't exist, but would be defined in paths.xml) would break the package.

There would need to be a standard naming convention that paths.xml would use, that would be built into software. I think pkg-config can do this, or is at least on the right track, but ALL software would need to adhere to this standard.

I agree, this would be really cool, but it won't happen any time soon. In the mean time, things work pretty well, and there are so many packages that need to be brought up to modern build systems that our time would be better spent elsewhere.

Using one of your examples, you said the Gaim could be compiled either with or without spelling support. Does that mean every single distro that has their own package manager is going to provide me two different packages? Even if they did, the overhead would be astounding. However, if there was a package management standard, in the case of Gaim, you'd have two different packages (one with spelling support and one without) that worked on every distro out there. What I'm saying is, even if you had to make 5-10 different packages to please everyone, why not only do it once instead of having every distro duplicating each other's efforts?

This is where distributions create policies with what types of add-on support should be available, and what should not. A well-behaved package will merely create extra files for each feature, and the program will detect the presence of said feature on startup. That way, in this example, you could have gaim-0.7.6-i386.rpm, and gaim-spelling-0.7.6-i386.rpm.

Being an end-user myself, if I'm looking for a particular package, I want it NOW - not 2 weeks from now and not 2 days from now. Call me demanding, but perhaps I've just been spoiled by using an OS for the past 11 years that provides this for me. The point I'm trying to make is that you can't change the demands of the user in order to compensate for the limitations in the package management systems .. it must be the other way around.

The problem is not having software unavailable, it's having software be slightly out of date for two weeks. I consider software released when I can easily install/upgrade it on my system, not when the source gets updated by the developers. Software seems to get updated faster in the Linux world than in the Windows world, so this is a tradeoff.

Lots of distributions have average update times of less than 3 days. I consider that fine. A new user won't even know the package was updated until the package gets updated. Plus, distributions are moving towards an automatic "every-night" update system, where you don't even pay attention to software being updated.

Yeah, that would be acceptable to me, assuming you could execute three commands (as it is supposed to work) and actually have it work with some degree of consistancy. As it stands, based on my own experience, it works maybe 30-40% of the time .. depending on if you have the right libraries and how complex the package is.

More software ought to use autoconf. In my experience, the percentage is closer to 80.

I think the difference between you and I is our attitudes. When I mention the idea of a standard for package managers, your automatic response is to come up with a list of reasons why it can't be done. My approach is simply to look at all the challenges facing us and trying to figure out how we can overcome them.

It could be done, but I don't see the reason why. If you just pick a distro and stick with it, where would the problem come from? Lots of Windows users get confused in Linux thinking that they need to go to the developers website, download, and install the software. In Linux, all of that gets taken care of for you. Waiting 2-3 days from the source release is a small price to pay for a new user having software installation made easier.

Also, having worked with many package managers, the differences between all of them are quite elementary, when you compare with pms of relatively equal feature sets.

Agreed. But instead of package maintainers having to make packages for each distro, why not make life easier so that whatever they do works in ALL distros?

The parent didn't mean that. One maintainer doesn't make packages for all the distros, each distro has maintainers that each make packages for several pieces of software.

Updating packages is trivial. Bump the version number, and possibly change some of the build commands. Fix bugs as they get reported.