producing nice tarballs
Duncan Coutts
duncan.coutts at worc.ox.ac.uk
Wed May 11 17:04:40 EDT 2005
Hi all,
With my Gentoo Haskell packaging hat on I'd like to grumble slightly :-)
There are a number of packages floating around that have various things
'odd' about them. It makes the lives of packaging people much easier if
tarballs follow a standard convention.
I suggest that the convention should be the same as what
autoconf/automake does in the C world (because this is what packaging
people are used to and what packaging tools work best with)
So if you've got a cabal package with fields:
name: FooBar
version: 1.2.3
Then the tarball should be "FooBar-1.2.3.tar.gz" (or .zip or .tar.bz2).
And that archive should unpack to "FooBar-1.2.3/".
There are packages around where the cabal package name is all lower case
but the tarball name is all upper case or mixed. Similarly there are
packages which unpack to just the package name rather name & version.
There are also packages with non-canonical version numbers, eg 5.01 gets
normalised to 5.1. Cabal identifies these two version numbers but it's
not clear that package authors are aware of this.
I know these seem like trivial issues but consistency makes things much
easier for (semi-)automatic tools.
With the rise of cabal, I think this is a great opportunity to have
tools that make it easy for package authors to "do the right thing". For
example, the C coders who use automake get package tarball preperation
for free. Indeed automake does some quite sophisiticated checks to make
sure that a source tarball is complete and consitent (it unpacks the
tarball, builds the package and uses it to produce another tarbal which
it compares to the original).
We (Gentoo packaging folk) are quite eager for cabal's "./setup sdist"
feature to be fixed/improved (apparently there are some issues with it
currently) so that package authors can be encouraged to use it and
produce consistent tarballs that will make packaging that bit smoother.
If it's not so high on everyone else's priority list we'll send
patches! :-)
Duncan
More information about the Libraries
mailing list