Bug#178809: rules for Build-Depends-Indep satisfaction make no sense
On Tue, Feb 11, 2003 at 06:55:37PM +0000, James Troup wrote:
> Julian Gilbey <jdg@polya.uklinux.net> writes:
>
> > > In that case, the buildds are broken: they don't install
> > > Build-Depends-Indep, even though they do invoke the clean and build
> > > targets of debian/rules (through dpkg-buildpackage). See
> > > http://buildd.debian.org/fetch.php?&pkg=freesci&ver=0.3.4a-2&arch=alpha&stamp=1043707174&file=log&as=raw
> > > for an example of this.
> >
> > Correct.
>
> No, it's not correct. The buildds are not broken, they're doing
> exactly what they've always done; you can't change policy and then
> declare that the buildds are broken because they don't follow how
> you've changed policy. Policy reflects current practice, remember?
I guess you're right. These packages will have to have workarounds
for the time being. The original intention of the whole -Indep split
was incorrectly described first time around in policy, and the buildds
dutifully followed the broken policy proposal.
As things stand with the buildds, the -Indep fields are almost
useless, and it may actually be worth dumping the -Indep field
altogether. tomcat, tomcat4, bigloo, bochs, dutch, gcc-avr,
grub-installer, gstreamer, httrack, hylafax, latex2rtf, libgcrypt,
libgnome, libgnomecanvas, libgnomeprintui, libgnomeui, librep,
libwnck, lilypond, ncbi-tools6, plex86, remstats, sawfish, sysstat,
yaboot-installer are the only packages in sid which are not
Architecture: all and which have a Build-Depends-Indep field. Of
these packages, many simply repeat certain Build-Depends packages in
the Build-Depends-Indep field, so don't need the field at all.
A few others are probably broken with the current buildd *and* policy
semantics (they are building for a single architecture but using
Build-Depends-Indep). A few are probably legal according to current
policy but broken for the current buildds.
So given how few packages we are talking about, would it be worth the
buildds using all packages specified in both Build-Depends and
Build-Depends-Indep and phasing out Build-Depends-Indep?
Another possibility is to modify the policy again to explain what the
buildds currently do and to stick with that.
Yet another possibility is to modify the buildds in the medium - long
term to do something like the following:
install Build-Depends
test whether debian/rules build-arch is a legal target (using -q
option, I think it is, assuming that debian/rules is a Makefile)
if so, run it, otherwise install Build-Depends-Indep and run
debian/rules build.
Of course, such an elaborate scheme is only needed if the package has
both Build-Depends and Build-Depends-Indep.
(Incidentally, console-cyrillic is the only Architecture: all package
to have both.)
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, website: http://www.polya.uklinux.net/
Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/
Visit http://www.thehungersite.com/ to help feed the hungry
Reply to: