On Sat, 7 May 2011 13:48:00 +0200 Enrico Weigelt <weigelt@metux.de> wrote: > * Neil Williams <codehelp@debian.org> schrieb: > > > Not every generated file needs to be cleaned. The list can vary if the > > package is very old and depends on how the package itself handles the > > clean internally. > > IMHO, *all* generated files should be cleaned away, just to be sure. > In the last decade I've encountered a lot of nasty problems w/ > forgotten generated files and similar stuff. 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. VCS is not the final source, it's a tool for upstream to create the final source. 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. I don't care what people say here, I am not putting the pre-tarball build stages into the upstream build system of my upstream packages. I usually document them in the README.svn but if it doesn't work, meh, use the tarball which I ensure does work. Overall, this has little to do with Debian. There is no consensus amongst upstream teams, no benefit in breaking stable projects by forcing a change in the build system and it just ends up as a simple preference by whoever has commit access to the upstream. If those people are happy with their own system, then arguing about tags versus tarballs is just bikeshedding. 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. > 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. 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. > 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. 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. Lunacy. It's elevating a tool into a stick to hit people with. I've only got one answer to that and it's NO. One method does not fit all. I've got no problem with teams who do want to use VCS tags as a release process but don't push your model on others. All you'll get from my upstream projects is tarballs and if the VCS tag doesn't build, I really don't care. There is no such thing as a "release tag" in my upstreams, there might be tags but those are often just experiments. > > Building direct from VCS is a nice idea but sometimes, it just isn't > > worth the pain - let the build system build the tarball and package > > from the tarball. It's just easier. Or just change the build system > > and/or the tool. > > 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. Indeed, in a few upstream projects, the only files which ever get tagged are the debian/ files. ;-) -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpACddkiQx3F.pgp
Description: PGP signature