* Yavor Doganov <ya...@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: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ---------------------------------------------------------------------- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100918072019.ge18...@nibiru.local