Re: Best practice for cleaning autotools-generated files?
* Neil Williams <codehelp@debian.org> schrieb:
> No. Reverting the build to the point where it is equivalent to only
> what is in the VCS adds completely unnecessary build dependencies and
> build stages.
Which ones exactly (besides the usual autotools) ?
> VCS is not the final source, it's a tool for upstream to create the
> final source.
Lets replace "VCS" by "SCM" to get to the whole picture.
I don't want to repeat the last decades if SCM theory and common
practies here, but one of the major goals of an SCM infrastructure
is that you always get can grab the source of some product in some
specific version and run a fully rebuild, anytime. _Reliable_
reproducability. Tarballs that are not fully-automatically produced
from the appropriate SCM tag (and can be reproduced anytime) simply
dont meet that requirement.
Maybe that all worked for you over many years. Fine.
For me it always never worked, starting with common things like
sysroot'ed crosscompiling (yes, I've propbably got a different
scope than you, I'm coming from the embedded front)
> I wouldn't want to work with any upstream which does not produce
> stable tarballs which are available for download without going
> anywhere near the VCS. I shouldn't even need to know what VCS is
> being used if all I want to do is build the package for my own use.
Guess what, I wouldn't work with upstreams that don't provide
reliable release tags in the VCS (an VCS that I can import to git).
Actually, I sometimes do, but it adds a lot of extra burden.
My buildsystem (called Briegel), doesn't even bother with things
like tarballs or patches (still supported, but unused for years now).
It simply grabs the source tree from git by a normalized ref (eg. tag).
Normalized means: there's a simple rule to transform a vector of
package name and (also normalized) version number into a ref name.
Period.
Any changes needed in the source tree are done through SCM.
(the processes behind may vary between individual packages).
And these efforts, prodiving (long term) stable source trees
is scope of the OSS-QM project (which acts as an intermediate
between the upstream and consumers like my Briegel-based
special-purpose distros).
> Overall, this has little to do with Debian.
True. It's a distro-agnostic issue. It's about how to be a good
upstream to make distro's lifes easier and extends into the whole
QM topics.
> If those people are happy with their own system, then arguing
> about tags versus tarballs is just bikeshedding.
This argument is only valid as long as you only consider official
upstream releases as your base. For example, I'm running automated
git imports and cleanups for certain packages where upstream doesn't
bother to provide a clean and stable source. You could use this,
or copy the machinery and run it on your own (IOW: join OSS-QM ;-p)
> Personal preferences have no place in a "best practice" statement -
> that way lies the hell of mandating which VCS gets used, pandering to
> whichever fanboy shouts the loudest.
Well, I wouldn't set any rule which VCS upstreams should use. That's
their choice. But they should provide anything that can be easily
imported (eg. into git). But as distro maintainers (from whatever
distro some might come from), we could agree to import all our required
source trees into some standardized SCM where anyone can grab the
(maybe cleaned) trees for a particular package/version automatically,
and additionally maintain our bugfix and/or tailoring changes there.
(-> OSS-QM ;-p)
> > A good rule, IMHO, is: take *only* the *actual* source files (those
> > written by the developers) and always regenerate all intermediate
> > steps. Of course this means, _never ever_ use prebuild configure
> > scripts etc.
>
> Fundamentally disagree.
Obviously, you almost never have to change the input files.
Or need to fix/tailor autotools. For mainline distros this might
work well, but in the embedded world you're easily out of luck
with this approach.
> That is a very, very, bad rule IMHO. ./autogen.sh is a valuable
> aid and it is pointless to try and assert that it should called
> in all builds. It can become necessary if the latest upstream
> tarball has gone stale but that's about it.
And it *IS* necessary, as soon as you have to change some of the
input files. In my daily projects, this happens on the majority
of the packages.
> > To go even one step further: dont use tarballs, instead upstream's
> > VCS release tags (assuming upstream provides that ;-o)
>
> ... and that is simply rubbish. Just because some teams want to use VCS
> tags does not mean that all upstreams would consider such a change.
True, not every upstream wants to do that. And not every upstream
wants to maintain stable releases. Well, that's life. Essentially
we have two options to cope with that:
a) everybody does the required fixups and workarounds all on its own
b) collaborate and provide a stabelized midstream together and so
save a lot of human workforce.
> As an upstream developer, I simply refuse. The VCS is for upstream,
> including the tags. What gets into distributions is the tarball because
> then I can be sure that the package builds with 'make distcheck' without
> using a new £$ %$£ branch for every "£$£" change between releases.
Why dont you just tag your releases properly ?
And did you ever consider that fact that certain downstreams would
like to use their VCS to rebase their changes to newer releases ?
> > Actually, when building directly from VCS release tag causes big pain,
> > upstream is doing something _seriously_ wrong. So: fix the upstream
> > or put in an intermediate project for the (distro-independent) QM
> > works. (-> OSS-QM project).
>
> NO. I am one of those upstreams and I do not care if any VCS tag causes
> pain to anyone when building. The tarball is the released code, use it
> or find someone else to package it.
You're aware of the fact that you're making life harder for downstreams ?
> Indeed, in a few upstream projects, the only files which ever get
> tagged are the debian/ files. ;-)
You tag individual files ?!
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
Reply to: