On Sat, 7 May 2011 15:41:22 +0200 Enrico Weigelt <weigelt@metux.de> wrote: > * 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) ? bison, flex and a few others. Also that certain stages of the transition from VCS checkout to tarball are not actually scripted anywhere, just described in a file. 'make distcheck' is an extremely useful sanity check with autotools packages. To do the check and then not distribute the results is just odd. To not do the check is negligent. > 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. Disagree. A tarball is easier to get hold of than some weird tag in an unfamiliar VCS. Common format, common methods to download and obtain it, simple URL's become possible instead of weird ones with ?=_, and other characters which rely on active parsing by a server instead of a simple directory listing. > Maybe that all worked for you over many years. Fine. It has indeed - about 10yrs at last count. > 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) Umm, please check www.emdebian.org - I am very deeply involved in all of the embedded activity in Debian and elsewhere. It's been my geek obsession since before I was a DD and it's now my full time employment. Personally, I dislike sysroot because it doesn't actually make my cross-building work any easier. I work mainly on a dpkg-cross based system, I wrote or improved nearly all of the scripts which currently support cross-building in Debian and prepared the only completely cross-built Debian distribution for ARM and released it alongside Lenny. I did some early work on the cross-building toolchains before handling that task over to Hector. I think I qualify as "embedded". Don't make assumptions - my embedded work isn't exactly hard to find. > > 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. Fine. That means that any difference on that issue is personal preference and has no place in any "best practice" guide or specification. Each preference works for those who prefer that method. Either the guide / spec steers well clear of the entire area or it gives 100% equal coverage to all of the possible preferences. > 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. Then your build system cannot cope with any of my packages. The point with Emdebian is that it must cope with all packages which might be useful, across most of Debian. > Any changes needed in the source tree are done through SCM. > (the processes behind may vary between individual packages). No, those should be done via patches, managed by dpkg-source format 3 or directly incorporated into the upstream tarball (which is how I prefer to do it). Depending on the purpose of the patches, the patch can go upstream or into the Debian package. > > 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. And that includes the ability to compare the checksums of tarballs included in the distributed sources of an embedded cross-built distribution to check that you really do have the same version as other distributions. It helps limit the amount of things which need checking when a bug only appears in one side. Normally, the cross-building process takes the most blame but there can be other issues. > > 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) I don't work with those upstreams - I work with the packages provided by other DD's who use those upstreams. As an upstream for my own packages, I don't bother to provide VCS release tags of any kind. > > 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) I never have seen any point in that. When preparing patches for an embedded distribution, it is pointless to modify the sources themselves. Provide patches in your own build system (i.e. debian/) and let people have the assurance that your sources match everyone else's by keeping the original tarball unchanged and putting your changes into either a .diff.gz or a .debian.tar.gz. > > > 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. Hah! Nonsense. If so, it's a problem with your embedded build system. I've done several thousand embedded builds of packages across all of Debian and the result? 99.99% of those packages ONLY needed changes in the debian/ directory to be able to cross-build and mostly any changes we needed to make to select different ./configure options were all done via debian/rules. > > 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. Nope. Not true. Not even slightly. I have several years of embedded experience with some 800 packages in Debian which prove the opposite. As above, this has been my daily experience for the last year - no changes are necessary to the upstream generated files unless the Debian package already needs such changes to build natively. i.e. cross-building is a complete red herring and I therefore claim that any difference between your experience and mine comes down to the difference in the build system, not the packages nor autotools. > > > 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. ... or just use the tarballs which exist in Debian where others have already done all that work for us. > > 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 ? Why should I? Who defines "properly"? Who benefits? The tarball is the stable release. Tags in VCS are irrelevant. > And did you ever consider that fact that certain downstreams would > like to use their VCS to rebase their changes to newer releases ? I doubt you can actually assert that this is a fact vs mere opinion with respect to my actual upstream packages. > > > 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 ? I doubt it. If you want to make that assertion, prove it in relation to my upstream packages. You are making universal claims which are manifestly individual preferences. I tend to keep old tarballs around for a few years after making a new release (roughly based on how long it will be before toolchain changes make it infeasible that anyone would seriously expect to be able to build that version). > > Indeed, in a few upstream projects, the only files which ever get > > tagged are the debian/ files. ;-) > > You tag individual files ?! Only occasionally. For experimental purposes only. Generally don't find tags useful in upstreams. Having said that, I do tag non-autotools packages habitually (like the emdebian perl script packages) but those are native to Debian. When doing Debian packaging of someone else's upstream, I use tags just for the debian/ directory because there's no reason to put the entire upstream source into the debian VCS. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgp78Rs6sgkdz.pgp
Description: PGP signature