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
Build-Depends-Min).
> 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.
MfG,
Eduard.
Reply to: