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

Re: Library packages depending on data files

Moin Adrian!
Adrian Bunk schrieb am Thursday, den 05. February 2004:

> > > > > E.g. the KDE maintainers did explicitely disallow installing multiple 
> > > > > so-versions of kdelibs at the same time.
> > > > 
> > > > Adrian, you should know better than most people here that this method sucks.
> > > 
> > > The most important question is the effect on users, and for users I
> > > don't see why this method sucks.
> > 
> > So not beeing able to upgrade KDE because it would cause the removal of
> > a dozen of other important packages is just okay for you?
> Debian users are supposed to stay inside one distribution (e.g. woody, 

Since your ideas would cause even a much longer delay (to sync the
development to a new library release), I cannot see your point.

> sarge). unstable is by definition often broken.

And it should by-definition serve the process of development, which
implies improval of software. Just saying "is simply broken so don't use
it at all" sounds childish for me.

> woody plus a more recent KDE or sarge plus a more recent KDE is simply 
> unsuported.

As said before, you expect that KDE+GNOME+dozens of other packages have
to be upgraded simultaneously (because we should throw away the
well-known methods of keeping multiple versions installed).

> That's similar to the situation with people demanding making it easy for 
> backporters:
> Packages in unstable must be suitable for unstable. It's nice if the 
> maintainer makes backporting easy, but if it's hard to backport a 
> package that is only the problem of the person doing the backport and 
> not a fault of the maintainer.

I can share only parts of your opinion. IMHO the best way would be to
introduce different Build-Dependencies, since Build-Deps are often
(mis)used to enforce transitions in Sid. There should be something like
Build-Depends-Min where the maintainer specifies the really neccessary
dependencies (eg. add gcc (>> 3) to Build-Deps and omit it in

> You tell me I should fix the testing scripts.
> You don't mention how the logic to fix it could be.
> I'd ask a different question:
> Are such problems fixable within the testing scripts with a reasonable 
> amount of work?
> testing has it's strengths, but also it's weaknesses - similar to many  
> other automatic tools, and there are classes of problems I don't think 
> testing will ever be able to handle.
> [1] even build dependencies are ignored
> [2] more exactly, they check whether the RC bug count for a package is
>     higher than the estimated RC bug count of the version of this 
>     package currently in testing

I am not a friend of testing either. It sucks because of generic flaws
in the idea, listed above. IMHO the packages should settle down by
recompiling them for a different set of libs. Instead of trying to
cripple Sid to make it "less harmful", we should create a proper
infrastructure to rebuild packages as-needed.


Reply to: