Re: A debian/rules target to rebuild pre-built stuff?
On Tue, Oct 25, 2011 at 11:54 AM, Russ Allbery wrote:
> Or do you mean that *if* someone uses this target, then a simple package
> build will test it? Hm, maybe. There are a lot of failures that will be
> caught that way, but some that won't (Autotools failures can just mean not
> finding supporting libraries, for instance).
Right. Hmm, I guess so.
> Either way, you're requiring the package maintainer to do the work to
> create a target that rebuilds all that stuff. It's actually somewhat more
> work to implement an optional target than to just make build do that. And
> either way, they're going to be responsible for making sure it works,
> except that under this proposal the buildds wouldn't test it for them.
The buildds would not, but hopefully those doing archive-wide rebuilds
would. Point taken anyways.
> I suppose there's the different between "should" and "must" which takes
> some of the pressure off (although I suspect that will just lead to people
> ignoring it).
Yeah I would expect it to be ignored a fair bit, "must" or not.
> I think I'd rather push people to use the dh add-on that regenerates all
> the autotools files, since that makes things relatively easy provided that
> the upstream files actually work with the latest versions.
While I also sometimes recommend, this isn't just about autotools.
One example from the archive: firmware-free. Source code for the
embedded software blobs is present but at least one of them no longer
builds or never did.
One example from outside the archive: MegaGlest is a game with images
rendered from 3D models, but those images are no longer possible to
render because the Blender API changed substantially in 2.50. In
addition the pre-rendered images are in the upstream VCS and the
models and blender stuff are in an external repository in an obscure
The other thing is that this is likely to substantially increase build
times, which might not be a good idea.