On Tue, 25 Nov 1997, Andreas Jellinghaus wrote:
> > No. We'll definitely not clutter our virtual package list just to support
> > some outside group distributing replacment packages for ours.
> >
> > I suggest that you leave the kde* packages as they are now (have been
> > before that change) so that they don't provide anything and that they
> > suggest each other where appropriate.
> >
> > Then, the KDE people can just call their packages "kde-kde*", "Conflict"
> > with your packages and "Provide" your packages. AFAIK, this would be
> > enough.
>
> this doesn't sound like cooperation.
> but what i want to do is : cooperate.
>
> neither we create the one and only official kde.deb, nor do they.
> we both create a kde.deb version, and both have the same value.
It's not a matter of value. The matter is that one kde.deb is part of the
Debian GNU/Linux distribution and the other is not. (That's the reason,
for example, why the first has to apply to our policy while the second
does not.)
> one side naming their package kde-kde* and the other one kde* doesn't
> sound that way. and both parties should use the conflicts (i want to be
> sure, that nothings goes wrong).
I don't see why we should make our packages "hot-swappable" with those
from someone else. Our goal is to create/maintain a complete (free)
operating system. That is, a collection of packages that configured to do
some useful job together.
Why should we handle the case that someone replaces some of our packages
by that of a third-party?
Of course, everyone is free to install any packages he/she wants to have,
but I don't think we have to handle this case.
After all, there shouldn't be any problems if the kde-kde packages
"Conflict:" and "Provide:" our kde packages and "Depend:" on theirs. This
should even avoid the case where both packages are mixed.
> and after all : it's only two entries ("kde-kde.deb-package" and
> "debian-kde.deb-package"), and these don't polute namespace.
>
> remember : the reason for a central organisation was :
> a) prevent namespace solution (this isn't the case)
> b) share a name between several maintainers (e.g. mail-transport-agent).
>
> both is not the case for kde*.
Generalizing your solution would mean, to let every package in the
Debian distribution have the following settings:
Package: foo
Provides: debian-foo
Conflicts: <third party>-foo, <fourth party>-foo, ...
This _would_ be a namespace pollution.
> > The only case where this might fail is when someone installs some packages
> > of ours and some of KDE's. After all, we are not responsible for the
> > damages if someone tries that.
>
> stop ! it's our users, and a very important goal is, to make it easy for
> our users. and if we exchange this very simple way to seperate the
> packages to something complicate or so, it's not in their intrest.
(Huh?) The question is _what_ we have to simplify. I think we have to
simplify installation, maintainance, etc. but not the case where someone
replaces our packages with those from someone else.
However, let me make another suggestion: We add a new control field to our
packages, namely `Distributor'. All Debian packages will get
`Distributor: SPI'
and everyone outside the project should use something else, e.g.
`Distributor: KDE Project' (or how they call themselves--I don't
know)
Then we could extend dpkg/dselect/deity to check for this field and warn
the user if he/she tries to mix such packages. Of course, there should be
a way to override these warnings (just when someone tries to override some
dependencies).
> sorry, but your solution is political, and not good.
> give me a good solution, and i'm happy to use it.
> the current way with two virtual package names works.
Of course, this is a political discussion, since it is about our goals.
You can't say whether a political standpoint is `good' or `bad'. But this
isn't the problem anyways. The problem is, which solution fits to our
project goals.
Thanks,
Chris
-- Christian Schwarz
[EMAIL PROTECTED], [EMAIL PROTECTED]
[EMAIL PROTECTED], [EMAIL PROTECTED]
PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
CS Software goes online! Visit our new home page at
http://www.schwarz-online.com
