Re: Library packages depending on data files
On Fri, Feb 06, 2004 at 02:44:36PM +0100, Eduard Bloch wrote:
> Adrian Bunk schrieb am Thursday, den 05. February 2004:
> > 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
I've often thought that I'd love to see something like this.
It can't go into policy until it's got some reasonable deployment, but
perhaps we could agree a specification on the -policy list and get it
into dpkg-checkbuilddeps and some number of packages?
> > 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.
> >  even build dependencies are ignored
> >  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.
Those aren't generic flaws in the idea. The first is fixable in the
testing scripts but just hasn't been done (aj is happy with the idea, I
believe, but it's more sensible to do it at the start of a release
cycle). The second should be fixable by bug tracking system
improvements, which as of recently are finally making progress again.
Colin Watson [firstname.lastname@example.org]