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: