Re: Library packages depending on data files

[Adrian Bunk <bunk@fs.tum.de>]

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 
unsuported.

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.

> > 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.

cu
Adrian

[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