[plug] Controversial comparison of distros?
James Devenish
devenish at guild.uwa.edu.au
Tue Oct 28 11:47:23 WST 2003
In message <20031028033353.GB2217 at lostrealm.com>
on Tue, Oct 28, 2003 at 11:33:53AM +0800, Leon Blackwell wrote:
> Note that no packaging format is perfect, and we'll never get
> distro-independent packaging until all distros follow the LSB and use
> exactly the same mechanisms for configuration and alternatives
> management.
I also wonder how 'configuration' would be handled in a
uniform-packaging utopia. For instance, there are some non-obscure
programmes for which I feel that RedHat has DANGEROUS defaults (I have
lost work, which makes me annoyed and astounded). RedHat's defaults
differ from those of the upstream package. Likewise, Debian's defaults
differ from those of the upstream package. I am accustomed to the
upstream packages more often than not (since I've not been much of a
Linux user). How will a uniform packaging system cater for different
people's desires? I have some sort of "trust" in Debian packaging that I
don't have for RedHat (never tried Mandrake or SUSE, etc.). However,
RedHat's defaults might be more appealing to novice UNIX users. These
differences in configuration might have implications for package
management, too.
As a developer, I would not like to be asked to cater for RedHat's or
Debian's configuration whims in my own software -- that remains their
concern. So, I would still think that RedHat and Debian should maintain
their own package systems. The idea of a standard package format could
THEN come in to play as a way for people to be able to safely install
the RedHat package or the Debian package or my package on their
computer. But if that's the case, I think .deb provides me with some
important ways of expressing my preferences that RPM does not provide. I
will probably find that the converse is true. Will have to find out.
_______________________________________________
plug mailing list
plug at plug.linux.org.au
http://mail.plug.linux.org.au/cgi-bin/mailman/listinfo/plug
More information about the plug
mailing list