[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: additional virtual packages for kde



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
                   schwarz@monet.m.isar.de, schwarz@schwarz-online.com
                  schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
                       
                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


Reply to: