[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: peless -- dh_helper



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: pgppw6s3weZom.pgp
Description: PGP signature


Reply to: