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

Bug#87510: I second this proposal



On Fri, May 18, 2001 at 01:31:30AM -0700, Chris Waters wrote:
> However, the proposal already has a sufficiency of seconds -- more
> make no difference at this point.

What Chris said.

> Back in Feb, aj said there were 2047 packages still needing build-
> depends.  If you want this proposal to take effect, the thing to do is
> not to blindly add YAUS (yet another useless second), but to address
> the objections, by NMUing or filing bugs to get the bloody packages
> fixed.
> 
> Then, when enough people have done enough of that work, someone can
> say, "hey, we've reached the point where there are only 200[*]
> packages left without build-depends -- aj and chris, does that answer
> your objections?"  And I, at least, would probably say yes at that
> point.  But until then, my objection stands.

The "2047" wasn't really all that accurate; it overestimates because it
counts packages w/o build-depends: fields that only need build-essential
packages to build (and thus don't need a build-depends filed at all).

A more accurate count can be obtained by using the build dependencies list
maintained by the autobuilders, at

   http://buildd.debian.org/andrea/i386/source-dependencies-unstable.gz

Given the cat'ed Sources file I keep around for testing, we can get a
list of packages that don't have build-depends: listed, but would need
them by something like:

	comm -12 <(grep-dctrl -v -F Build-Depends -s Package -r '.' org-testing/data/unstable/Sources | sed 's/^Package: //' | sort) <(lynx -source http://buildd.debian.org/andrea/i386/source-dependencies-unstable.gz  | grep '^[^#]' | sed -n '1,/^zsh:/p' | sed 's/:.*$//' | sort)

(I love shell one liners. Sue me.)

There are 424 of them, by my count. That is probably an underestimate,
if the autobuilders haven't got build-depends listed in andrea for all
the packages that need them. andrea might also be missing packages that
only depend on debhelper or similar.

For some context: [within sid/unstable]

	source packages:        4652 [0]
	packages w/ b-d:        3187
	packages w/o b-d:       1465
	packages missing b-d:    424

So that's 9% of all packages, 13% of all packages that need build-depends.

There are two flaws with this proposal. One is that it's completely
wrongheaded to declare something RC when a significant number of packages
don't do it already. The other is that it's completely wrongheaded
to convert a policy from being entirely optional (you /may/ declare
build-depends) straight to being compulsory.

I'm not sure why people seem to refuse to get this, it's really quite
simple. It's quite simple to get this into policy too: change the
musts to shoulds, make sure we all know which packages are affected
(and make sure that's as few as possible), and make sure the solution
you're proposing is actually workable.

An additional problem in practice if not theory is that build-depends
are difficult to get right. People who like the idea of build-depends
are invited to look through the current RC bug list and note just how
many of our RC bugs at the moment are of the form "maintainer screwed
up the build-depends".

Cheers,
aj

[0] That's 368 new packages since last I tried doing stats about this
    proposal...

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
                      -- John S. Novak, III (The Humblest Man on the Net)

Attachment: pgp3lCaVGWHtP.pgp
Description: PGP signature


Reply to: