Gentoo Archives: gentoo-dev

From: Martin Schlemmer <azarah@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Glibc, non-glibc and external libs
Date: Thu, 16 Jun 2005 14:20:09
Message-Id: 1118931213.11254.4.camel@lycan.lan
In Reply to: Re: [gentoo-dev] Glibc, non-glibc and external libs by "Diego 'Flameeyes' Pettenò"
1 On Thu, 2005-06-16 at 15:47 +0200, Diego 'Flameeyes' Pettenò wrote:
2 > On Thursday 16 June 2005 00:02, Diego 'Flameeyes' Pettenò wrote:
3 > > There are other solutions a part the new virtuals?
4 > Ok just to summarize.
5 >
6 > a) getopt_long isn't important right now, FreeBSD 5 already takes care of it,
7 > if in the future it will be necessary for NetBSD, OpenBSD or DragonFly, it
8 > will be another issue.
9 >
10 > b) most of the packages requiring gettext at runtime already requires it at
11 > build time atm... the simple thing to do is moving this on runtime on the
12 > packages which needs when we'll stumble across it
13 >
14 > c) main problem is libiconv, but this is required just by a few packages
15 > (gettext, glib2, bogofilter) the other uses it with gettext; as they doesn't
16 > require a specific version, we can also add dev-libs/libiconv to glibc's
17 > PROVIDE and just depend on dev-libs/libiconv.
18 >
19
20 The issue I guess is that unlike it seems the common belief in the bsd
21 camp is, virtuals is not the ultimate cure for all that is twisted.
22
23 Rather do something like:
24
25 DEPEND="!userland_GNU? ( dev-libs/libiconv )"
26
27 (or '!elibc_glibc?' if that is more relevant if it might be needed for
28 uclibc/whatever)
29
30 Just keeping on heaping virtuals for everything is not the only way. Or
31 just pull them in the profile.
32
33
34 --
35 Martin Schlemmer
36 Gentoo Linux Developer, Desktop/System Team Developer
37 Cape Town, South Africa

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] Glibc, non-glibc and external libs "Diego 'Flameeyes' Pettenò" <flameeyes@g.o>