* Yavor Doganov <ya...@gnu.org> schrieb:
> That's exactly where --with-zlib and --with-libbz2 should be used
> (according to the practice recommended by Autoconf, at least).
> --enable-compression could by default check for zlib and libbz2, and
> enable either or both if found. If neither is found and
> --enable-compression was manually specified by the installer, the
> configure script should fail with a proper error message.
Wait a minute - we're talking about two different features here!
zlib and libbz2 are not compatible in their data formats (_not_
a choice between to functionally equal implementations). So there
_MUST_ be reliable way to switch them, and maybe have both enabled
at the same time (otherwise people will suddently find their data
unaccessible).
A proper naming would be --enable-compression-zlib and
--enable-compression-libbz2. Maybe we're choosing actual file
formats, then it will be --enable-compression-zip and
--enable-compression-bzip2
> > You doubt the whole embedded/smalldev development going all around
> > the world ?
>
> I admit I'm not familiar with this topic ("embedded/smalldev
> development"). If static libraries are really needed there, and this
> is an area Debian strives to support, I guess the stance about static
> libs should be widely discussed.
There already had been many discussions in recent years. In the end
it all depends on the concrete situation. Sometimes shared objects
(when really _shared_ in-memory) pay out the overhead of dynamically
loaded objects, even under low-memory/-cpu constraints, but most
times they dont. Leave that decision to the distro and provide a
generic solution to both as upstream.
> > No, it's not. Actually, it's quite fine. Just give it the right
> > environment variables, so it takes everything from sysroot.
>
> That's what I'm talking about. You don't need to play with PKG*
> variables if pkg-config macros are *not* used.
But if it's not used, you'll get into lots of other trouble.
For example, dependencies: not everybody uses ELF shared objects
for libraries. (see above: static linking). And the it's generic
interface allows injecting other things (eg. target-specific
ld options for individual libraries)
Of course, we could talk about a new library metadata format
(where the .so* files are just one part of it), which is directly
supported by the toolchain, but that's a whole different front
and would require much heavier changes to package sources as
well as toolchain implementations.
> > And you suppose all the individual distro maintainers to manually
> > tweak each package for each target ?
>
> Of course not. A proper usage of the GNU Build System does not
> require pkg-config, and certainly does not require manual tweaks.
Please define "proper usage" exactly.
> > 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 !)
>
> This interface contradicts the Autoconf philosophy (i.e., perform
> realistic feature tests, not merely version comparisons), which is why
> some developers do not like and/or trust its approach. Others do,
> which is also fine.
That's exactly where Autoconf is wrong by design: it tries to guess
everything, with no generic interface for specifing things from
the outside whatsoever (no, injecting arbitrary config cache values
doesn't count here). Machine trying to be smarter than humans.
> I don't see why Debian should insist on upstreams to be in the former
> or the latter group. Really.
I never claimed that Debian should do so. These are *my* rules, *I*
insist on source packages following these rules - if upstream doesn't
want to comply, I'll make my own downstream branch in OSS-QM.
My intention of posting it here was to let you all know about it,
and talk about that.
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/20100921100708.gb13...@nibiru.local
