Kari Pahula <k...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
