Re: additional virtual packages for kde
Hello everybody!
I must say I don't like the course of this discussion. It looks like this
will eventually turn into yet-another flame war. To prevent this, please
let us stick to the facts and forget about all `wrong assumptions,'
`prejudices,' etc.
Note, that the topic of this discussion is very general. Therefore, we
should not consider it too `personal.' Furthermore, it has nothing to do
with previous political discussions about our relationship to KDE. The
same discussion could be held about any other third party e.g., the FSF.
Now to the facts. The situation is the following: A third party
distributes .deb's on the Internet which are meant to be installed on a
Debian system.
First of all, this is actually a very good thing! One of our goals is to
build a free operating system which can be extended and redistributed by
others. So we should actually be happy that KDE decided to distribute
packages in our favoured package format.
In this special situation, it happens that we distribute the same piece of
software in our distribution. Again, this is not bad. It's clear, that our
packages have to comply with our policy and that the other packages don't
have to. So there is a good reason to have two different set of packages.
As the different packages comply to different standards (I think the file
system structure is the most important difference between these packages)
they are not compatible. Thus, if someone tries to mix packages of both
sets, he/she is likely to get troubles.
Now, there are two solutions: (a) both sides change their packages so that
they are compatible or (b) it's guaranteed that one cannot mix packages of
both sets. (Solution (a) might obsolete one set of packages.)
Solution (a) would mean that both groups (Debian and KDE in this case)
find a compromise. As long the required changes on our parts would comply
with current policy I would support such a solution. However, it looks to
me in this case (now this is a prejudice, perhaps) that the differences
are in the file system structure only and that KDE wants to stick to a
single directory tree. We've already discussed this in detail and decided,
to stick to FSSTND (FHS in the future). Thus, this solution does not work
in this case. (Note, that this conclusion is based on a prejudice. Perhaps
Andreas can report if this is really the case.)
Solution (b) would mean to either add `flashing notes' to the READMEs that
warn the user about mixing the packages or to use dpkg's dependency
mechanism to not allow the mix. Probably, both things should be done.
Now to the critical point: I don't think it's our job to change our
packages in such a way that some third party (hear: KDE) can replace them.
In fact, I think it's the third party's job to fix _their_ packages so
they integrate into the Debian system well and don't allow mixing with our
corresponding packages.
Here is the reason for this: By changing our packages so that they are
compatible with packages from someone else we would give away some piece
of our freedom and independence.
Let me give you two examples to clarify this: Suppose that we are one week
before a stable release, that is, the distribution is already frozen. Now,
if a third party changes their packages, we would have to change our
packages, too. This can't be a good solution.
Another example: There are so many people on the Internet that there are
definitely a few out there which can't be trusted. Consider someone
releasing a Debian package called `perl' (note, that Perl is an essential
part of our distribution) which executes `rm -rf /' in its preinst script.
Now, are we responsible for the damage this package would cause to our
users just because we have some packages in our distribution that actually
depends on a `perl' package? No. Obviously we are not responsible for
that. (Note, that this is only theoretically, since by our disclaimer we
cannot be made responsible either way.)
So, if some of our users get .deb's from a third party they are
responsible themselves for any damage that package could cause. If there
are incompatibilities between our system and these packages, then the
third party should try to inform the users about that and provide
necessary dependencies on their packages.
However, it might be a good idea to label our packages to come from SPI so
that our users know which packages were distributed by which vendor.
Ideally, this would be done with digital signatures (e.g., PGP) so that
no-one else can claim that his/her packages come from us.
Implementing something like an `Origin' control field might be a more
simple solution for now. With that, dpkg could be extended to issue
appropriate warnings when installing packages from a third party. (Note,
that as this might also have some disadvantages we would need an extra
discussion for such a new control field.)
Now back to our concrete problem: I suggest to leave our packages as they
are now (I'm referring to version Beta1.2-1.1 hear, since I don't have a
new version available right now). If the KDE people change their packages
to something like the following dependencies, everything should work fine.
(If there are problems with this solution, please tell me.)
Package: kde-kdelibs0g
Conflicts: <insert names of all Debian KDE packages here>
Package: kde-kdebase
Depends: kde-kdelibs0g, ...
Conflicts: <insert names of all Debian KDE packages here>
Package: kde-kdegrahics
Depends: kde-kdelibg0g, kde-kdebase, ...
Conflicts: <insert names of all Debian KDE packages here>
Thanks for your attention,
Chris
-- Christian Schwarz
schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Don't know Perl? schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/
Reply to: