[gentoo-dev] Glibc, non-glibc and external libs

[gentoo-dev] Glibc, non-glibc and external libs

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

The problem with external libraries which are needed on non-glibc systems (not 
sure about uclibc) to have GNU-style functions is getting bigger.

Not only we need to depend on gettext and libiconv, but there's now also 
another library, gnugetopt which provides getopt_long function non non-glibc 
systems.

This is going to be a problem, because waiting for new virtuals for those will 
take a lot of time and Gentoo/FreeBSD is slowed down by this a lot.

I'm asking for a quick solution because Gentoo/FreeBSD is proceeding well but 
this is hurting the possibility to have all the depends cleaned out.

There are other solutions a part the new virtuals?
-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Glibc, non-glibc and external libs

[Olivier Crete]

On Thu, 2005-16-06 at 00:02 +0200, Diego 'Flameeyes' Pettenò wrote:
> The problem with external libraries which are needed on non-glibc systems (not 
> sure about uclibc) to have GNU-style functions is getting bigger.
> 
> Not only we need to depend on gettext and libiconv, but there's now also 
> another library, gnugetopt which provides getopt_long function non non-glibc 
> systems.
> 
> This is going to be a problem, because waiting for new virtuals for those will 
> take a lot of time and Gentoo/FreeBSD is slowed down by this a lot.
> 
> I'm asking for a quick solution because Gentoo/FreeBSD is proceeding well but 
> this is hurting the possibility to have all the depends cleaned out.
> 
> There are other solutions a part the new virtuals?

Why dont you just add them to the profile as system packages ? 

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Glibc, non-glibc and external libs

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]

On Thursday 16 June 2005 01:13, Olivier Crete wrote:
> Why dont you just add them to the profile as system packages ?
I though of that but I'm not sure about it. I wish to have a systme profile as 
cleaner as possible and libiconv, gettext and other packages aren't needed 
for a lot of different packages because they doesn't use them.
When I fist needed to install libiconv in the Gentoo/FreeBSD I was tinkering 
with, was just because I needed it ot have glib2 working for irssi.. I was 
already using that box as ftp and mail server.
So I much prefer having them just when needed and not "because it's possible 
that someone uses them", else it will be exactly as they were in the libc 
(one of the key strengths of *BSD is the fact that the libc is minimal and 
this makes the things simpler to maintain).

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Glibc, non-glibc and external libs

[Mike Frysinger]

On Wednesday 15 June 2005 06:02 pm, Diego 'Flameeyes' Pettenò wrote:
> another library, gnugetopt which provides getopt_long function non
> non-glibc systems.

tracking packages which need getopt is a waste of time, just force it in your 
profile/bsd libc/whatever

i dont see why this should affect any packages
-mike

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Glibc, non-glibc and external libs

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

On Thursday 16 June 2005 06:22, Mike Frysinger wrote:
> tracking packages which need getopt is a waste of time, just force it in
> your profile/bsd libc/whatever
it's not getopt, it's getopt_long... which is used by few packages.
well actually freebsd provide it in library in latest releases, aslo if it's 
developed on its own... maybe I can hack a bit the build process to have this 
external as we need.

This doesn't remove the problem on libiconv/gettext anyway.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Glibc, non-glibc and external libs

[Duncan]

Diego 'Flameeyes' Pettenò posted
<200506160441.44787@enterprise.flameeyes.is-a-geek.org>, excerpted below,
on Thu, 16 Jun 2005 04:41:34 +0200:

> On Thursday 16 June 2005 01:13, Olivier Crete wrote:
>> Why dont you just add them to the profile as system packages ?
> I though of that but I'm not sure about it. I wish to have a systme
> profile as cleaner as possible and libiconv, gettext and other packages
> aren't needed for a lot of different packages because they doesn't use
> them.

What about dual-tracking?  You say a virtual works but getting it setup is
slow.  You say the profile option works but you don't want to use it due
to bloat.  So... what about kicking off the virtual process now, but put
it in the profile temporarily as well, avoiding having to wait for the
virtual process, with a comment on the profile entry reminding you to
review it with an eye for removal if the virtual process is done, say for
2006.0.

After all, if it's not really required for what folks are doing and they
don't want the bloat, they can package.provided it, as I've done with a
couple things (I HAD to with sash, as I never COULD get the thing to
compile here on amd64, for whatever reason, maybe it requires Linux
Threads and I run nptl-only??? who knows?), so profile system entries
don't make things ABSOLUTELY mandatory.

Seems the reasonable thing to do, here, but then again, I'm likely missing
something.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Glibc, non-glibc and external libs

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

On Thursday 16 June 2005 07:58, Duncan wrote:
> So... what about kicking off the virtual process now, but put
> it in the profile temporarily as well, avoiding having to wait for the
> virtual process, with a comment on the profile entry reminding you to
> review it with an eye for removal if the virtual process is done, say for
> 2006.0.
Well as Gentoo/FreeBSD isn't even released I can't say what I need to do for 
2006.0... always if we're going to follow Gentoo's releases instead of 
FreeBSD's ones, I'd actually tend for the latter because their base system 
releases are quite tight between them.

Anyway, I prefer avoid having to mess with profiles in this way, as our 
profile already needs a lot more loving than the base ones as atm we don't 
inherit from them (profiles in overlays can't inherit profiles's in main 
portdir), adding more cruft over this is going to be a great problem to 
maintain.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Glibc, non-glibc and external libs

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

On Thu, 16 Jun 2005 08:18:30 +0200
"Diego 'Flameeyes' Pettenò" <flameeyes@gentoo.org> wrote:

> Anyway, I prefer avoid having to mess with profiles in this way, as
> our profile already needs a lot more loving than the base ones as atm
> we don't inherit from them (profiles in overlays can't inherit
> profiles's in main portdir), adding more cruft over this is going to
> be a great problem to maintain.

They can inherit from $PORTDIR profiles, assuming that you know t
he values of $PORTDIR and $PORTDIR_OVERLAY, just figure the relative
path out. Of course that's a problem if you can't rely on defaults and
a cleaner solution is needed anyway (probably coming with profiles2).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Glibc, non-glibc and external libs

[Thomas de Grenier de Latour]

On Thu, 16 Jun 2005 11:26:40 +0200
Marius Mauch <genone@gentoo.org> wrote:

> They can inherit from $PORTDIR profiles, assuming that you know
> t he values of $PORTDIR and $PORTDIR_OVERLAY, just figure the
> relative path out. Of course that's a problem if you can't rely
> on defaults and a cleaner solution is needed anyway (probably
> coming with profiles2).

Bug #83613 maybe? That's a rather trivial patch, and i think it
would help a lot for distributing some non-official profiles.

-- 
TGL.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Glibc, non-glibc and external libs

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

On Thu, 16 Jun 2005 11:41:59 +0200
Thomas de Grenier de Latour <degrenier@easyconnect.fr> wrote:

> On Thu, 16 Jun 2005 11:26:40 +0200
> Marius Mauch <genone@gentoo.org> wrote:
> 
> > They can inherit from $PORTDIR profiles, assuming that you know
> > t he values of $PORTDIR and $PORTDIR_OVERLAY, just figure the
> > relative path out. Of course that's a problem if you can't rely
> > on defaults and a cleaner solution is needed anyway (probably
> > coming with profiles2).
> 
> Bug #83613 maybe? That's a rather trivial patch, and i think it
> would help a lot for distributing some non-official profiles.

As a short term solution maybe, don't really like the restriction to
$PORTDIR though (practically not relevant though, just don't like
special cases).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Glibc, non-glibc and external libs

[Mike Frysinger]

On Thursday 16 June 2005 12:33 am, Diego 'Flameeyes' Pettenò wrote:
> On Thursday 16 June 2005 06:22, Mike Frysinger wrote:
> > tracking packages which need getopt is a waste of time, just force it in
> > your profile/bsd libc/whatever
>
> it's not getopt, it's getopt_long... which is used by few packages.
> well actually freebsd provide it in library in latest releases, aslo if
> it's developed on its own... maybe I can hack a bit the build process to
> have this external as we need.

yes i know the diff between getopt and getopt_long, that doesnt change the 
fact that tracking either is a waste of time
-mike

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Glibc, non-glibc and external libs

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

On Thursday 16 June 2005 00:02, Diego 'Flameeyes' Pettenò wrote:
> There are other solutions a part the new virtuals?
Ok just to summarize.

a) getopt_long isn't important right now, FreeBSD 5 already takes care of it, 
if in the future it will be necessary for NetBSD, OpenBSD or DragonFly, it 
will be another issue.

b) most of the packages requiring gettext at runtime already requires it at 
build time atm... the simple thing to do is moving this on runtime on the 
packages which needs when we'll stumble across it

c) main problem is libiconv, but this is required just by a few packages 
(gettext, glib2, bogofilter) the other uses it with gettext; as they doesn't 
require a specific version, we can also add dev-libs/libiconv to glibc's 
PROVIDE and just depend on dev-libs/libiconv.

What about this?
-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Glibc, non-glibc and external libs

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

On Thu, 2005-06-16 at 04:41 +0200, Diego 'Flameeyes' Pettenò wrote:
> When I fist needed to install libiconv in the Gentoo/FreeBSD I was tinkering 
> with, was just because I needed it ot have glib2 working for irssi.. I was 
> already using that box as ftp and mail server.

HAHAHAHA....

Thanks a ton!  I actually had removed irssi from my uclibc-based LiveCD
build because of this.  Now I should be able to add it back.  Whatever
you come up with on this for Gentoo/FreeBSD will also be needed for
uclibc.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Glibc, non-glibc and external libs

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

On Thu, 2005-06-16 at 15:47 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Thursday 16 June 2005 00:02, Diego 'Flameeyes' Pettenò wrote:
> > There are other solutions a part the new virtuals?
> Ok just to summarize.
> 
> a) getopt_long isn't important right now, FreeBSD 5 already takes care of it, 
> if in the future it will be necessary for NetBSD, OpenBSD or DragonFly, it 
> will be another issue.
> 
> b) most of the packages requiring gettext at runtime already requires it at 
> build time atm... the simple thing to do is moving this on runtime on the 
> packages which needs when we'll stumble across it
> 
> c) main problem is libiconv, but this is required just by a few packages 
> (gettext, glib2, bogofilter) the other uses it with gettext; as they doesn't 
> require a specific version, we can also add dev-libs/libiconv to glibc's 
> PROVIDE and just depend on dev-libs/libiconv.
> 

The issue I guess is that unlike it seems the common belief in the bsd
camp is, virtuals is not the ultimate cure for all that is twisted.

Rather do something like:

DEPEND="!userland_GNU? ( dev-libs/libiconv )"

(or '!elibc_glibc?' if that is more relevant if it might be needed for
uclibc/whatever)

Just keeping on heaping virtuals for everything is not the only way.  Or
just pull them in the profile.


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Glibc, non-glibc and external libs

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

On Thu, 16 Jun 2005 15:47:35 +0200
"Diego 'Flameeyes' Pettenò" <flameeyes@gentoo.org> wrote:

> c) main problem is libiconv, but this is required just by a few
> packages (gettext, glib2, bogofilter) the other uses it with gettext;
> as they doesn't require a specific version, we can also add dev-libs/
> libiconv to glibc's PROVIDE and just depend on dev-libs/libiconv.
> 
> What about this?

Sorry, but it's not a good idea to PROVIDE non-virtuals. Creates all
kinds of problems (just search for the gcc-4.7 bug).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Glibc, non-glibc and external libs

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]

On Thursday 16 June 2005 16:13, Martin Schlemmer wrote:
> DEPEND="!userland_GNU? ( dev-libs/libiconv )"
I'd like to do that but there was disagreement about this before.
For me is enough.

> Just keeping on heaping virtuals for everything is not the only way.  Or
> just pull them in the profile.
As I said, I'm not considering adding libiconv to profile as an option, it's 
not directly required.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Glibc, non-glibc and external libs

[Mike Frysinger]

On Thursday 16 June 2005 11:51 am, Diego 'Flameeyes' Pettenò wrote:
> > Just keeping on heaping virtuals for everything is not the only way.  Or
> > just pull them in the profile.
>
> As I said, I'm not considering adding libiconv to profile as an option,
> it's not directly required.

that's fine, but i *still* dont see why putting 'nls? ( libiconv )' into 
PDEPEND of bsd libc isnt acceptable

no, bsd libc doesnt directly require libiconv, but if you're using a 
bsd/Gentoo system and you have USE=nls, what are the chances you *dont want* 
libiconv ?
-mike

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Glibc, non-glibc and external libs

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

On Thursday 16 June 2005 18:07, Mike Frysinger wrote:
> no, bsd libc doesnt directly require libiconv, but if you're using a
> bsd/Gentoo system and you have USE=nls, what are the chances you *dont
> want* libiconv ?
Quite a few as 'nls' useflag is already used by freebsd's libc for other 
means.
Maybe an iconv useflag can be acceptable, too? this probably would be better 
but still... when we'll have use-flags deps we should add the right deps.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]