* Neil Williams <codeh...@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: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ---------------------------------------------------------------------- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110507134121.GE25423@nibiru.local
