Re: RFC: Rules for distro-friendly packages
* Russ Allbery <rra@debian.org> schrieb:
> 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.
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).
Ofcourse you can provide multiple different tarballs or different
compressions.
> 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.
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.
> 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.
With build output I mean the compiled files (binaries, etc) - not the
logs, of course. The problem is that certain packages look for runtime
properties like availble memory, availability of certain devices, etc,
and suddenly produce different code.
> 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.
Switching dependencies which silently enables/disables features is
a generally bad approach. Instead have feature switches and maybe
tell what these features depend on.
> 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. And still many people need them.
> one can not yet commit to a stable ABI, and there are
Why that exactly ?
> various situations (such as support for dynamic plugins) where supporting
> them is a huge pain.
In very most cases, that's bad design.
> 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.
Changing ABI simply *has* to be reflected in the soname. Period.
If some lib doesnt do that, it simply fails the test. Perhaps rude,
but necessary to ensure quality.
> 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.
Yes, but that's a build system speficic issue and so will be stated
in the appropriate sections (yes, the text is not finished yet).
> I strongly disagree with requiring pkg-config.
Well, actually, I need it, eg. for clean sysroot'ed crosscompiling.
> None of my libraries support this,
Bad. You should fix 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>.
Because that doesn't always suffice. It requires that the library
is in the toolchain's standard search path. And what about cflags ?
What about dependencies ?
> You don't need pkg-config to figure that out.
No, but it makes it *MUCH* easier.
> It's a nice-to-have if upstream wants to bother, but is absolutely
> not required.
For my setups, it *is* 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.
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.
> 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.
Then you'll have to live with the fact, that other people won't
like your libraries very much, for that reason.
> 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),
Nobody is forced to use them.
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
Reply to: