Enrico Weigelt <weig...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878w31fg8a....@windlord.stanford.edu