Re: Autobuilding and the build-arch target, again
On Mon, Jan 23, 2006 at 06:36:40PM +0100, Simon Richter wrote:
> To summarize the proposals so far:
>
> - "Scan debian/rules, invoke build-arch if present".
>
> Has been tried, does not work.
AFAIK it is working as long as you assume debian/rules to be a Makefile,
which is a pretty safe assumption considered it is mandated by policy.
We had a talk about this in #debian-tech some days ago, and the general
consensus seemed to be that somebody should submit a patch for that to
dpkg.
I have attached the log.
cheers,
Michael
<dato> okay. if somebody familiar with the build-{arch,indep} in rules story
wants to comment, I think this could work out (but have to re-read
#218893; did a while ago but did not make myself a summary):
<azeem> dato: I think dpkg-buildpackage needs to get changed to call build-arch
if available
<azeem> but I don't recall the whole discussion
<dato> make Policy require the presence of build-{arch,indep}; this will need a
bump of Standards-Version, and of course packages are free to provide
the trivial implementation only.
<dato> then, since dpkg-buildpackage receives a .dsc as argument, _check_ the
Standards-Version of that package, and invoke build-arch if appropriate
(dpkg-buildpackage -B) iff it's >= whatever verison introduced the
"must".
<dato> err.
<azeem> why shouldn't dpkg-buildpackage -B not just check whether build-arch is
there, and call that?
<dato> s#receives a .dsc as argument#has debian/control available#
<dato> azeem: because a big part of the discussion was about how hackish, error
prone, and even impractical in some cases, that approach was.
<dato> otoh, if a package updates its S-V, and does not provide build-arch,
that's a serious bug...
<dato> but otoh^2, I'm not sure what the Policy editors will think about this,
but I see really no other way out.
<dato> aba?
<azeem> why can't we just make binary-arch: depend on build-arch: instead of
build?
<dato> because dpkg-buildpackage calls build first (as non-root), and
binary-arch afterwards.
<azeem> it does?
<azeem> indeed
<azeem> so I thought somebody came up with a sane way of checking for build-arch
<azeem> which, OTOH, relied that debian/rules be a Makefile, which some people
dispute (though Policy mandates it AFAIK)
<dato> http://lists.debian.org/debian-policy/2004/05/msg00006.html
<dato> my personal order of preference is (1) Standards-Version bump, (2)
Build-Options, (3) Do nothing about the issue, (4) autodetect the
existance of build-arch
<azeem> what's wrong with what keybuk proposed? (i.e. make --dry-run | grep
^build-arch)
<dato> keybuk proposed (2), didn't he?
<dato> ah
<dato> I read backwards.
<azeem> I didn't really read the first paragraph the first time round :)
<azeem> on the third try, I think I parsed it correctly, and went back to my
initial reading...
<aj> aiui, historically, the reason is because the dpkg maintainer (wiggy)
wanted to support #!/bin/sh debian/rules riles
<jvw> fwiw, S-V bump detection in dpkg seems by a great length the most sane
choice to me
<aj> atm Standards-Version is only advisory
<azeem> wouldn't the make -f check just fail then, and we assume no build-arch?
<aj> i'm all for (4) -- immediate functionality with no extra changes, and
pretty minimal breakage
<jvw> (1) also gets our hands dirty in getting a bit a better way to be able to
introduce policy changes without making half the archive instanta-buggy
<azeem> did somebody send a good patch for (4) in, yet?
<jvw> it's very much against current practice, that no demand in policy can do
that, and that any demand in policy applies per direct to all packages,
but from a practical POV, being able to gradually introduce stuff into
policy this way is nice
<azeem> we could also test it on one of the lesser important buildds for a
while, e.g. (like armeb or hurd-i386, dunno=
<jvw> of course, it requires demanding a certain minimum version of policy after
a limited period
<azeem> I really don't see the point in mandating build-arch
<azeem> it is useful for a lot of packages, but pretty irrelevant for a lot as
well I guess
<aj> having an environment variable that indicates binary: doesn't need to build
arch:all stuff is another option, though the functionality isn't as
immediate then
<DavidS> azeem: probably so that lesser (in terms of power) arches don't need to
build huge masses of useless, because never uploaded documentation?
<azeem> DavidS: yes, but this can be introduced gradually for the packages which
needs it most
<azeem> instead of changing the whole archive
<DavidS> azeem: not as long as stuff like dpkg-bp use build?
<azeem> DavidS: sure, I am assuming we go for (4)
<DavidS> azeem: ah, reading helps (I did miss your earlier statements as context)
<azeem> so, let's see. If we changed d-b to check for build-arch, that'd mean
older d-b would make the package FTBFS, right?
<azeem> or maybe not
<aj> no, build: implies build-arch+build-all
<azeem> right
<azeem> so binary-arch would depend on build-arch instead of build
<aj> yes
<aj> don't they already do that often?
<azeem> and the old d-b would just continue to build the indep stuff
<azeem> probably. So we could start transitioning packages right away
<aj> binary-arch: apt libapt-pkg-dev apt-utils
<aj> mostly they seem to do that instead
<aj> (or depend on build)
<azeem> now here is where CDBS is handy
<aj> at least the random ones i have
<azeem> what does dh_make do these days?
<azeem> a lot of packages will just have that
<azeem> binary-arch: build install
<azeem> actually, CDBS won't be handy, because there is probably no way to tell
it what to do in build-arch and build-indep, or at least it is not
widely used
Reply to: