Re: Proposed release goal: fix debian/rules build-arch
Kari Pahula <kaol@debian.org> writes:
> I know some people would like to see a lintian check, first. The thing
> is, debian/rules is a program, so trying to figure out any properties
> about it, like "does it support feature X?" or "does it halt?" gets
> quite close to the halting problem.
>
> GNU make does have some options to query a makefile, like --dry-run and
> --question. Even those would require evaluating a makefile, at least to
> some degree. If someone put $(shell rm *) in there, it'd do that. I'd
> like to see something like "Running debian/rules --dry-run or --question
> must not have harmful side effects or affect any subsequent calls to
> debian/rules." in the policy before relying on those. I'm hoping that
> there's nothing controversial about this addition. IMHO it's a rather
> pathological makefile that does things like that.
Such a requirement unfortunately still won't mean that Lintian can use
that option to do a check of debian/rules. As long as make is willing to
run such code, we can't just rely on a Policy statement saying that you're
not supposed to do that. It is, among other things, a security problem.
You should be able to run Lintian on a package of unknown origin and
provenance and not have it be able to do things that you don't want. What
we would need is a make option that ensures that make would never run such
code, and unfortunately that's likely to lead to false positives in some
of the stranger cases.
Lintian can go a long way by scanning debian/rules. This mostly fails
with build systems like CDBS (but one can generally assume that they'll do
the right thing) and hand-rolled build systems involving includes or more
fancy trickery. Lintian can't get the latter right, but they're also
fairly rare.
There are also the few packages in the archive that don't have a makefile
as debian/rules. I've been tempted for some time to file RC bugs against
all of them.
http://lintian.debian.org/tags/debian-rules-not-a-makefile.html
> Option 4 (give up):
>
> Remove the mention of "build" from 7.7.
I assume you mean build-arch and build-indep here. I would go a step
further and deprecate Build-{Depends,Conflicts}-Indep if we go that route,
remove the corresponding Lintian checks, and start letting people simplify
their debian/control files.
> Policy would match the current usage, right then. This is not what I'd
> like to see, since I think that a reliable build-arch would be a really
> nice thing to have.
I have to admit that I'm tempted by this approach, mostly because it's not
clear to me that the build-arch vs. build-indep separation actually gains
us anything that useful. The point, so far as I can tell, is to save
buildd time by not building the architecture-independent packages. How
much time would we actually be saving? Is it worth putting a lot of human
effort into making that situation possible? Generally CPU cycles are far,
far cheaper than human cycles.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: