Re: RFC: Rules for distro-friendly packages
Enrico Weigelt <weigelt@metux.de> writes:
> * Russ Allbery <rra@debian.org> schrieb:
>> You've prohibited upstream distributions that come in multiple tarballs.
> With that I mean that you don't need to unpack multiple tarballs to
> get a working tree (Xorg/Xf86 was such a case, several years ago).
Right. And I'm saying now that our packaging tools can handle that case,
it's not clear to me why Debian should be telling upstreams they must not
do that. (Although I'm increasingly getting the impression that your list
of guidelines is documentation of your personal coding style, not really
an effort to put together guidelines that Debian as a whole can agree to
advocate to upstreams.)
>> 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).
> Runtime test suites are different thing. I'm talking about the build
> process.
Oh, okay. Maybe that should be somewhat clearer?
> What I want to prohibit is such cases where you start the build and it
> now starts some downloads or queries some servers, etc, all that risks
> making the build indeterministic and thus unreliable.
Yes, I agree with that.
>> 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.
> They should use --enable-*/--disable-* flags for switching features.
--enable/--disable is for internal features. --with/--without is for
features that depend on external packages. See the Autoconf
documentation.
> Switching dependencies which silently enables/disables features is a
> generally bad approach. Instead have feature switches and maybe tell
> what these features depend on.
Best practices for use of Autoconf is to force building the feature with
--with, force omitting the feature with --without, and to auto-detect
based on the presence of the external library if neither is given. This
is what we should be recommending to upstream to use, IMO.
>> 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
> Building static libraries (additional to shared/dynamic ones) usally
> is not a big task.
Except when it is, such as whenever you want to use some sort of dynamic
plugin architecture, which is increasingly common. See also PAM modules,
NSS modules, etc.
> And still many people need them.
I'm dubious of this.
>> one can not yet commit to a stable ABI, and there are
> Why that exactly ?
Why do upstreams not commit to a stable ABI? Usually because the software
is still under rapid development and they're not keeping track of which
changes change the public ABI. It's not uncommon for libraries in their
very early stages of growth.
>> various situations (such as support for dynamic plugins) where
>> supporting them is a huge pain.
> In very most cases, that's bad design.
Um. I'm not sure there's anything I can say to that other than "no, it's
not."
>> I strongly disagree with requiring pkg-config.
> Well, actually, I need it, eg. for clean sysroot'ed crosscompiling.
I doubt this a lot. Details?
>> None of my libraries support this,
> Bad. You should fix this.
No. I don't believe it's very important or at all necessary, and since I
don't use pkg-config myself and don't plan to start, it's not particularly
important. While I'll probably do something about it eventually when I
have some free time, it's very low on my priority list. I completely
disagree with any statement about upstream build practices that require
it.
>> 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>.
> Because that doesn't always suffice.
Then use pkg-config or some other tool in the rare cases where it doesn't.
> It requires that the library is in the toolchain's standard search
> path.
That's what user-settable LDFLAGS in Autoconf is for, and that handles the
search paths for all libraries, whether they're using pkg-config or not.
> And what about cflags ? What about dependencies ?
Most libraries do not need either of those things on any modern platform.
Are you really writing your guidelines to cater to HP-UX and IRIX? I
agree that this sort of thing is useful there, but there are numerous
other portability issues to platforms that can't handle shared library
dependencies. Most software is not going to build on those platforms
anyway, since doing so requires access to those platforms to do reasonable
testing and realize what changes have to be made.
Sure, if you're going to the work to port your software to ancient UNIX
platforms without shared library dependencies, then by all means add
something like pkg-config for library consumers to handle library
dependencies. I've ported some things to that sort of environment, and
those are the first places where I'd consider pkg-config (although,
notably, no one has yet asked for it and no one who actually builds my
software on IRIX or HP-UX has ever indicated that it would save them any
time). But one of the things that makes software packages unnecessarily
complex in my opinion is cargo-cult portability. If you're not in a
postition to actually test on that platform, and don't have knowledge of
the pitfalls of portability to that platform to adjust accordingly,
wasting time on adding bits and pieces of portability glue that supposedly
make things better there just complicates your package and wastes your
time.
For example, it's always slightly amusing to look through a large
collection of Autoconf-using open source software and see how many of
those packages have calls to AC_FUNC_SETVBUF_REVERSED in their
configure.ac files. That check is a probe for a problem that hasn't
existed since 1987, the software packages almost never correctly handle
the case where that macro returns the unexpected result, and in modern
Autoconf (in recognition of that) it now just silently does nothing. Yet
it sticks around in many software packages as cargo-cult portability,
sometimes with some preprocessor goo that purports to handle the results
(but usually doesn't).
It's particularly entertaining to see software with calls to that macro
which then unconditionally calls mmap. :)
>> 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.
> It could have been named "wurstbrot" or whatever, but fact is, most
> packages name it that way and so it's an de-facto standard. And
> standardization is one of the major aspects of these rules.
The standardization of this particular interface (which is of only slight
utility; people use all sorts of other conventions already) is not
important enough to warrant uglified names, IMO.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: