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

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
> Build-Depends-Min).

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

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                                  [cjwatson@flatline.org.uk]

Reply to: