On Fri, 25 May 2007 15:28:17 -0500 Paul Elliott <pelliott@io.com> wrote: > I will probably make a release probably Sat or Sun. > > It will take this long because I still have to verify that the > system still builds on Fedora, opensuse, mandrake and ubuntu 7.04. > I still do not have a debian sid system for testing, but if > ubuntu works other debian based systems will probably work possibly > with minor changes. That seems a lot of work for a single (small?) program. Personally, I wouldn't say it was worth it. I used to do all this multi-distro testing for my own upstream projects - I still have a laptop somewhere with FC5 on it for this reason. Guess what happened - yes, I wasted days and days on retests using distributions I rarely used myself only to find that the maintainers of the code for those distributions were ignoring my .spec files and using their own - and with FAR better results. Eventually, I learnt that it is all pointless. Upstream cannot be a packaging expert for all distributions and should not seek to become one. Even if you test on FC, OpenSuse, Mandriva, Ubuntu and Debian, does that help people who want to use gentoo or slackware? - let alone installations like fink or cygwin (or OpenEmbedded and Emdebian for that matter). All I do now is test on two *architectures*, not multiple distributions. I have an amd64 workstation and a powerpc laptop and as these are very dissimilar platforms, I test on each - yet both are running Debian unstable. (I do have i386 but those boxes are not usually powered up.) I have 7 upstream projects using autotools in this way. I also cross-build some packages for arm but that's just me, I'm not recommending that as a build test! Leave the distribution specific stuff to those who are specialists in that distribution (another reason why no upstream package should contain a debian directory). By all means make a test package for whatever is your preferred distribution but it is hardly ever worth packaging those - 99 times out of 100 the actual package will use a different spec file and there is nothing wrong with that. Upstream should be completely distribution-neutral, except in very unusual circumstances. You're using autotools! Make use of them. The only thing upstream ever needs to do, IMHO, with an autotools source build is ensure that the source code completes 'make distcheck' successfully before every release - that's it. It doesn't matter what distribution is used to run 'make distcheck' because it tries quite hard to be distro-agnostic. Then, if the package fails to build on FC or Debian or gentoo, the likelihood is that people very familiar with those distributions will be able to determine why 'make distcheck' works on one and not on theirs because the failure is likely to be something quite obvious due to the number of packages running 'make distcheck'. A package that completes 'make distcheck' will usually build correctly on Debian and elsewhere and will install the required files where Debian packaging tools would normally expect to find them without upstream needing to know anything about debhelper. Packages that fail 'make distcheck' will usually fail to build on most, if not all, other distributions. I usually try to ensure that every upstream package completes 'make distcheck' after each work session in CVS/SVN but it's not really necessary unless you are making any changes to configure.ac, any Makefile.am or adding or removing files from the build (like translations). Please don't reinvent the wheel. If you have sensible test programs setup to run via 'make check' and you are already running 'make distcheck' successfully, I'd recommend releasing immediately. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpRHyElX4lDV.pgp
Description: PGP signature