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

Re: Library packages depending on data files

On Thu, Feb 05, 2004 at 11:41:45AM +0100, Eduard Bloch wrote:
> Moin Adrian!
> Adrian Bunk schrieb am Wednesday, den 04. February 2004:
> > > > Why?
> > > > 
> > > > 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, 
sarge). unstable is by definition often broken.

woody plus a more recent KDE or sarge plus a more recent KDE is simply 

That's similar to the situation with people demanding making it easy for 
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.

> > The way testing works, if both libv0 and libv1 can go into testing,
> > proga can enter testing years before progb.
> Then fix testing scripts.
> > Exactly this was observed with KDE and GNOME:
> > KDE 2.2 in testing was horribly outdated, but it was consistent, and 
> > when KDE 3 entered testing, a complete KDE 3 entered testing.
> > OTOH, the transition from GNOME 1 to GNOME 2 happened step for step, and 
> > I know several people who switched to unstable since the GNOME in 
> > testing was unusable.
> As said, fix the testing migration. You should not fix one bad thing
> creating another bad one.

testing uses simple and easy understandable rules to decide when to put
a package into testing: The testing scripts only check the dependencies
[1], whether a package was built on all architectures it was ever built
on, and check RC bugs [2].

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.

> MfG,
> Eduard.


[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


       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply to: