[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: Rules for distro-friendly packages

* Yavor Doganov <yavor@gnu.org> schrieb:

> > 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.

No, opposite direction: features are functional requirements, whose
implementations just happens to have some dependencies. For example,
an feature could be supporting compressed files, implemented using
zlib or libbz2.

> 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.

True. Therefore the missing packages will have to be fixed.
> > And still many people need them.
> I seriously doubt that.

You doubt the whole embedded/smalldev development going all around
the world ?

> Many Debian library packages have been gradually dropping static
> libraries in the past few years, and I don't recall complaints.

Debian isn't actually a embedded distro.

> If someone really needs a static library, she is probably in a perfect
> position and has the necessary knowledge/skills to build one herself.

Yes, he/she'll have to fix all those packages, and maintain the 
fixes over a long time. Actually, several parties (including OSS-QM)
are doing that. But this adds unncessary burden on them, draining
resources from the actual goals.

> > > 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...  

No, it's not. Actually, it's quite fine. Just give it the right
environment variables, so it takes everything from sysroot.

> With pure Autoconf macros (used properly, and providing an extra
> argument for AC_RUN_IFELSE and friends), cross-compilation works
> out of the box.

And you suppose all the individual distro maintainers to manually
tweak each package for each target ?

> > 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.

It's easier to control those things via a generic interface like
pkg-config (note: I'm talking about the _interface_, not just the
binary /usr/bin/pkg-config !)

> > And what about cflags ?  What about dependencies ?
> What's wrong with checking for the libraries/headers in the right
> dependency order?

Where do you (as application developer) know about the whole
dependency chain for all the imported libraries from ? Try it
all out manually and then hardcode it ? What's when dependencies
change in newer versions of one of them ?

> 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, 

That's all it has to do. Oh, a bit more: it follows the dependency
chain, and maybe does some fixups (eg. in sysroot builds).

> 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).  

So, you prefer complete test suites dor all your dependencies
in your importing package ?

> 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.

A question of proper release engineering. If you're not happy with
certain upstream's releases, fix them and submit patches.
> You are basically right that using pkg-config is easier for many
> upstreams, but "easy" != "correct".  Correctness is far more
> important.

True. Tell that the upstream devs if they messed up something.
My rules are designed to help finding out those things.

> 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).

Ah, so he should also do much manual work, which could be fully
automated ?

> > 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.

When I encounter such cases, I fix them. At the source of the
problem. If it gets too complicated, I drop them in favour of
better choices (eg. I don't support Qt/KDE stuff at all, I don't
even have it on any of my systems).

> > 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.

I don't want state anything about his code's quality before I had
a closer look at it. But not providing pkg-config descriptors
simply let it not pass my QM process.

 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: