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