Re: RFC: Rules for distro-friendly packages
Enrico Weigelt wrote:
> * Russ Allbery <rra@debian.org> schrieb:
> > You're basically saying that people aren't allowed to use
> > the typical Autoconf semantics of honoring --with and --without
> They should use --enable-*/--disable-* flags for switching features.
--with and --enable have different semantics, although they're often
misused and/or confused by upstream authors. See (autoconf)External
Software' and the subsequent node, `(autoconf)Package Options'.
> Switching dependencies which silently enables/disables features is
> a generally bad approach.
Well, in my very humble experience, an optional dependency is there
precisely to provide an optional feature.
> > 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.
I guess what Russ is trying to say is that they are completely useless
if just one library package in the dependency chain doesn't provide a
static lib.
> And still many people need them.
I seriously doubt that. Many Debian library packages have been
gradually dropping static libraries in the past few years, and I don't
recall complaints. I think the statement "many people need them" is
an exaggeration.
If someone really needs a static library, she is probably in a perfect
position and has the necessary knowledge/skills to build one herself.
As you say, that's easy :-).
> > I strongly disagree with requiring pkg-config.
>
> Well, actually, I need it, eg. for clean sysroot'ed crosscompiling.
But pkg-config is notoriously bad when cross-compiling... With pure
Autoconf macros (used properly, and providing an extra argument for
AC_RUN_IFELSE and friends), cross-compilation works out of the box.
If PKG_CHECK_MODULES is used, the installer has to go through extra
hoops.
> > None of my libraries support this,
>
> Bad. You should fix this.
I don't think so. It's entirely his prerogative whether to support it
or not, and it's perfectly fine not to use 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. It requires that the library
> is in the toolchain's standard search path.
That's the case with pkg-config too. If you install a library in
/opt/foo, pkg-config will not find it if you don't instruct it to look
there.
> And what about cflags ? What about dependencies ?
What's wrong with checking for the libraries/headers in the right
dependency order?
Honestly, I've always wondered what's so attractive in pkg-config that
people use it so much. All it does is parsing a .pc file, which fails
short in so many situations... The version check pkg-config does is
simply a comparison with the version embodied in the .pc file, which
does not match the reality in some cases, and more importantly, is the
wrong approach -- the version check may succeed, but the library may
not provide the feature needed by the package (improper installation,
distro patch, sysadmin patch, forked software, anything else the
package developer *has not* anticipated). And vice versa, which is
equally annoying -- the library provides the symbol (or the new
feature) the package needs, but the .pc file still contains the old
version, because usually it's bumped at release time. Ugh.
You are basically right that using pkg-config is easier for many
upstreams, but "easy" != "correct". Correctness is far more
important. I also fail to see what has pkg-config to do with
distro-friendliness. A distro maintainer by definition should be
familiar with the code, follow upstream development, examine diffs
between upstream releases (in the ideal case), and add the appropriate
build-dependencies when the new upstream version of the package needs
them (or could benefit from them). pkg-config is not in the picture
at all.
> > It's a nice-to-have if upstream wants to bother, but is absolutely
> > not required.
>
> For my setups, it *is* required.
Then you probably can't build lots of packages. Many widely used
libraries with a truckload of reverse dependencies do not support
pkg-config, and there's nothing wrong in that.
> > 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.
That is an utterly wrong assumption, and I even find it slightly
insulting because it presumes that the quality of Russ' software is
somewhat lower than expected.
> > 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),
Very true.
> Nobody is forced to use them.
Fortunately.
Reply to: