OSNews

contrasutra
Once again, file system structure is opinion as well. There is already the Standard File System Hierarchy, but that provides flexability. Some distros like /opt, some don't. Some use /usr/local, some don't.
Changing UNIX, which is over 30 years old isn't going to happen.

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.

For example, look at the standard Mozilla binary for Linux. I believe it still uses GTK1 and no Xft. I have an LCD monitor, and un-antialiased fonts (Xft provides the AA) are unbearable. Luckily, Arch's package has Xft/GTK2 enabled, so I'm fine. Different strokes for different folks. I wouldn't use Mozilla if I could only use their standard package.

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?
Even still, shouldn't an option like spelling/no spelling be something that can be turned on/off at runtime? What if I compile without spell checking and then decide later on that I want it? Do I have to re-compile the whole thing again? That's just lame. Contrast this with MS Word where I can just tick/untick a checkbox in order to turn it on and off.

Another easy example is binary compatibility. The easiest way to make sure you don't have glibc/gcc issues is for the package maintainers to rebuild things when they break (due to upgrading gcc/glibc).

Ok, so if we need multiple versions of gcc/glib, why not provide them all as part of the distro install? Sure, we'd be wasting some disk space, but if that is necessary, I think many users would gladly trade disk space for simplicity.

Well, all the distros I mentioned earlier have a forum/mailing list/something. If a package is out of date, just make a post and it'll be updated.

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.

And I understand how the package would work, but there is already a "standard" distribution method that you seem to be missing. That's the source tarball.

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.

Like I said, the developer should only have to release that and the package maintainers will compile and build a package for you.

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?

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.

dpi[/i]
Now, where do this OSS world of yours argument against competition? Don't you think that if that were true, there would never been something like Emacs given Vi already existed?

Alright, let's use your example of Emacs and vi and say that a standard for storing ASCII text? You would have each app both doing their own thing, and one would probably be incompatible with the other. So in the case of plain ASCII text, you've got plenty of text editors (providing competition) that are all using the same standard, thus being compatible with each other. Competition and compability - the best of both worlds. That, IMHO, is how it should be.
You don't have to have each distro using incompatable 'standards' (even if their OPEN standards) in order to have healthy competition. I shudder to think of where the WWW would be without any kind of standard for HTML. I guess if the OSS community had anything to do with it, we'd have about 100 HTML 'standards' and each browser would only implement one or two of them.