Re: RFC: Rules for distro-friendly packages
Enrico Weigelt <weigelt@metux.de> writes:
> I've collected several rules that upstreams should follow to make
> distro maintainer's life much easier:
> http://www.metux.de/index.php/de/component/content/article/57.html
> Free feel to comment on it :)
You've prohibited upstream distributions that come in multiple tarballs.
Now that our source format can handle that, I think that prohibition is a
bit too strong, although it's still less convenient.
The test suites for my packages do network communication on localhost.
It's completely impossible to test a lot of network code if you don't
allow this. But your build system point currently says that's not
allowed. I think you should allow localhost network communication for the
test suite (although not the main package build).
The way that the point about build output not varying based on the runtime
properties of the building system is both confusingly stated (by "build
output" I would have assumed you meant the textual output from the
compiler to the screen, not the constructed binaries) and I think way too
restrictive. You're basically saying that people aren't allowed to use
the typical Autoconf semantics of honoring --with and --without flags and
autodetecting an optional dependency if neither is given, but that's best
practice. Instead, I think you should say that it must be possible to
pass flags into the build system such that the build will always either
produce the same binaries or will fail, not silently drop features that
have been explicitly requested (or silently add features that have been
explicitly disabled).
I disagree with requiring static libraries even with the exception that
you list. In this day and age, I think static libraries are basically
useless unless one can not yet commit to a stable ABI, and there are
various situations (such as support for dynamic plugins) where supporting
them is a huge pain.
Libraries should NOT build shared libraries if they can't commit to a
stable ABI with proper SONAME changes when it changes. Yes, that sucks,
and there should be a stable ABI, but if there isn't, static-only is
better than an unstable shared library ABI not reflected in SONAME
changes.
I think you should specifically call out DESTDIR as the mechanism that
should be supported for specifying the installation location even if
Autoconf is not used. Everything else is more annoying to use, and
supporting DESTDIR with hand-written Makefiles is not that hard.
I strongly disagree with requiring pkg-config. None of my libraries
support this, and I don't see any point in using pkg-config if the way
that one uses the shared library is to just add -l<library-name>. You
don't need pkg-config to figure that out. It's a nice-to-have if upstream
wants to bother, but is absolutely not required.
I absolutely refuse to call my autogen script autogen.sh for the same
reason that I oppose putting language extensions on any executable. Linux
is not Windows; we don't need to call things foo.bat and bar.exe.
My packages will not be using pkg-config when pkg-config doesn't do
anything useful or when I can reproduce its results in more supportable
ways. The pkg-config Autoconf glue is ugly and does not properly
implement Autoconf semantics (for example, it incorrectly merges CPPFLAGS
and CFLAGS, and LIBS and LDFLAGS, and is not written using modern Autoconf
features and style), and is not something I'm willing to use or support
unless I absolutely have to.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: