to, 2005-01-13 kello 04:07 +0000, Scott James Remnant kirjoitti:
> The stats:
>
> 8,920 source packages in Debian unstable main.
> 8,254 declare a build-dependency on debhelper
>
> = 92% of packages build-depend on debhelper.
>
> Is that sufficient to declare it build-essential?
Hm, I get slightly different numbers:
$ awk '/^Build-Depends/ { $1 = ""; print }' Sources | tr , '\n' | \
awk '{ print $1 }' | sort | uniq -c | sort -nr | head
8278 debhelper
895 perl
820 cdbs
752 xlibs-dev
556 autotools-dev
508 dpatch
460 zlib1g-dev
409 gettext
386 libncurses5-dev
379 libgtk2.0-dev
The exact numbers are not, however, important. It is clear that
debhelper is by far the most popular explicit build dependency, by an
order of magnitude. (Incidentally, there seems to be a few packages that
explicitly build-depend on build-essential, which is probably not what
the package was meant for.)
The Policy Manual says this about build essential packages:
It is not necessary to explicitly specify build-time
relationships on a minimal set of packages that are always
needed to compile, link and put in a Debian package a standard
"Hello World!" program written in C or C++.
I don't think debhelper fits into this category. On the other hand,
build-essential (version 10.1) already depends on file, html2text,
debconf-utils, and po-debconf, which I think are also not necessary for
building a "hello, world" program.
I happen to think that explicit dependencies are in general better than
implicit ones. Being explicit tends to simplify things. We invented
build-essential, however, because having to explicitly build-depend on,
say, perl all the time is more error prone than having the dependency be
implicit. perl (not just perl-base) is, in practice, on every Debian
machine used for building packages, and if one had to explicitly
build-depend on it, there would be lots of accidentally missing build
depedencies on it. This would result in needless FTBFS bugs, if nothing
else.
I don't think debhelper is in the same category as perl is: pretty much
all packages that need it already properly build depend on it. (The rest
could be fixed.)
I don't mind debhelper becoming build-essential, but I don't think
that's what build-essential was really meant for. If we expand its
meaning, we should probably clarify its description in the Policy Manual
as well.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
