Mailing List Archive

> And, on a more general note, don't bother depending on a package listed
> in base/packages. It's pointless and just create more noise.

It's seems to be needed sometimes b/c it does change the order of generated
deplist(emerge -e world). AFAIK some packages dep on zlib b/c of that.

--
Best Regards,
Piotr Jaroszyński

--
gentoo-dev@gentoo.org mailing list

On Sun, 10 Dec 2006 03:22:52 +0100 Piotr Jaroszyński <peper@gentoo.org>
wrote:
| > And, on a more general note, don't bother depending on a package
| > listed in base/packages. It's pointless and just create more noise.
|
| It's seems to be needed sometimes b/c it does change the order of
| generated deplist(emerge -e world). AFAIK some packages dep on zlib
| b/c of that.

It's necessary for some system packages, yes. In general, unless your
package is likely to be included in part of system, there's no need to
specify system dependencies.

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster : http://ciaranm.org/show_post.pl?post_id=61

On Sun, 10 Dec 2006 03:22:52 +0100
Piotr Jaroszyński <peper@gentoo.org> wrote:

> It's seems to be needed sometimes b/c it does change the order of
> generated deplist(emerge -e world). AFAIK some packages dep on zlib
> b/c of that.

If you don't know about the unwritten yet near universal exception
clause then you shouldn't be invoking it.

--
gentoo-dev@gentoo.org mailing list

> It's necessary for some system packages, yes. In general, unless your
> package is likely to be included in part of system, there's no need to
> specify system dependencies.

Have a look at equery d zlib and e.g. bug #151708

--
Best Regards,
Piotr Jaroszyński

--
gentoo-dev@gentoo.org mailing list

Hi,

Am Sonntag, den 10.12.2006, 03:22 +0100 schrieb Piotr Jaroszyński:
[...]
> It's seems to be needed sometimes b/c it does change the order of generated
> deplist(emerge -e world). AFAIK some packages dep on zlib b/c of that.

Same thing applies for app-portage/portage-mod_jabber.

Greetings, Lars
--
"Kriterium des Wahren ist nicht seine unmittelbare
Kommunizierbarkeit an jedermann"
-- Theodor Wiesengrund Adorno, aus: »Negative Dialektik«

name: Lars H. Strojny web: http://strojny.net
street: Engelsstraße 23 blog: http://usrportage.de
city: D-51103 Köln mail/jabber: lars@strojny.net
f-print: 1FD5 D8EE D996 8E3E 1417 328A 240F 17EB 0263 AC07

On Mon, 11 Dec 2006 11:03:18 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:

> Could you spell out that exception clause, please?

It doesn't translate well into words, but we'll go with something like
"Unless you know exactly why the rule is there, understand fully the imp
--
gentoo-dev@gentoo.org mailing list

On Mon, 11 Dec 2006 11:35:34 +0000
Stephen Bennett <spb@gentoo.org> wrote:

> On Mon, 11 Dec 2006 11:03:18 +0000
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>
> > Could you spell out that exception clause, please?
>
> It doesn't translate well into words, but we'll go with something like
> "Unless you know exactly why the rule is there, understand fully the
> imp

My mail client, touchpad, and right hand are retarded. That should read:

"understand fully the implications of breaking it, and know why it's a
good idea in this particular case."

However, if you're in a position to be invoking that clause, you should
know about it anyway.
--
gentoo-dev@gentoo.org mailing list

On Sat, 16 Dec 2006 12:46:30 -0600 Ryan Hill <dirtyepic@gentoo.org>
wrote:
| Stephen Bennett <spb@gentoo.org> wrote:
| > > Could you spell out that exception clause, please?
| >
| > It doesn't translate well into words, but we'll go with something
| > like "Unless you know exactly why the rule is there, understand
| > fully the implications of breaking it, and know why it's a
| > good idea in this particular case."
| >
| > However, if you're in a position to be invoking that clause, you
| > should know about it anyway.
|
| Can we skip the sekrit rulez crap and just spell it out? Really, how
| does this help anyone?

It's quite simple. You don't do it unless you are fully aware of the
consequences. If you have to ask, you aren't fully aware of the
consequences so you mustn't do it.

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster : http://ciaranm.org/show_post.pl?post_id=61

Ciaran McCreesh wrote:
> On Sat, 16 Dec 2006 12:46:30 -0600 Ryan Hill <dirtyepic@gentoo.org>
> wrote:
> | Stephen Bennett <spb@gentoo.org> wrote:
> | > > Could you spell out that exception clause, please?
> | >
> | > It doesn't translate well into words, but we'll go with something
> | > like "Unless you know exactly why the rule is there, understand
> | > fully the implications of breaking it, and know why it's a
> | > good idea in this particular case."
> | >
> | > However, if you're in a position to be invoking that clause, you
> | > should know about it anyway.
> |
> | Can we skip the sekrit rulez crap and just spell it out? Really, how
> | does this help anyone?
>
> It's quite simple. You don't do it unless you are fully aware of the
> consequences. If you have to ask, you aren't fully aware of the
> consequences so you mustn't do it.
>

Which clearly doesn't answer Ryan's question... but hey... that's a
Ciaran answer...

Basically the idea is that Ciaran and spb can protect their image as the
all knowing gods of programming. In other mailing lists they would be
considered trolls and/or Debian devs/users.

--
Doug Goldstein <cardoe@gentoo.org>
http://dev.gentoo.org/~cardoe/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Doug Goldstein wrote:
> Ciaran McCreesh wrote:
>> On Sat, 16 Dec 2006 12:46:30 -0600 Ryan Hill <dirtyepic@gentoo.org>
>> wrote:
>> | Stephen Bennett <spb@gentoo.org> wrote:
>> | > > Could you spell out that exception clause, please?
>> | >
>> | > It doesn't translate well into words, but we'll go with something
>> | > like "Unless you know exactly why the rule is there, understand
>> | > fully the implications of breaking it, and know why it's a
>> | > good idea in this particular case."
>> | >
>> | > However, if you're in a position to be invoking that clause, you
>> | > should know about it anyway.
>> |
>> | Can we skip the sekrit rulez crap and just spell it out? Really, how
>> | does this help anyone?
>>
>> It's quite simple. You don't do it unless you are fully aware of the
>> consequences. If you have to ask, you aren't fully aware of the
>> consequences so you mustn't do it.
>>
>
> Which clearly doesn't answer Ryan's question... but hey... that's a
> Ciaran answer...
>
> Basically the idea is that Ciaran and spb can protect their image as the
> all knowing gods of programming. In other mailing lists they would be
> considered trolls and/or Debian devs/users.
>
All right, all the trolling needs to stop. Please direct your flames at
the closest brick wall.

- --
=======================================================
Mike Doty kingtaco -at- gentoo.org
Gentoo/AMD64 Strategic Lead
Gentoo Council
Gentoo Developer Relations
Gentoo Recruitment Lead
Gentoo Infrastructure
GPG: E1A5 1C9C 93FE F430 C1D6 F2AF 806B A2E4 19F4 AE05
=======================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iQCVAwUBRYSDAIBrouQZ9K4FAQI1SAP/eIuXRpqypo8wdbtfISgmhtbMICczjl1d
aZrALxsATSWnmQjy7E9E2B2A7iFKQxIyCKXlUusoDtTooGmBegXALZzgQ7oOL3gt
YJFcP0YjFTLnwfpfwauVMfYJGB/ClmGze0nVNyGfU2dSt4eWY9zLw9Ai90v2jGPX
U0B+VjlnLpY=
=f/Mj
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

Ryan Hill wrote:
> Ryan Hill <dirtyepic@gentoo.org> wrote:
> If it's universal, then why isn't it written somewhere? After all
> this, we *still* haven't gotten an answer to why some packages
> outside of the system target are depending on zlib. Is this a bug? If
> not, what's the reason it's there? Let's document this reason, so we
> don't have to go through this again in the future. It's that simple.

Hrm, I thought I wrote about this a while ago but I don't see it on
archives.g.o so lets try again.

> If your package is 'not important' meaning it will never be in 'system'
> for any profile, you should not depend on anything in 'system', as
stuff in system should already be installed in a given (sane) configuration.
>
> If your package may be in 'system' in a given profile, you need to
ensure your package builds in the proper order, with regards to other
system packages. The classic example is zlib; if you need zlib to
uncompress something, then you should put zlib in the deps; that way
when someone is building say, a stage1, your package will build after
zlib, instead of before it.
>
> You have to be careful in deciding what to specify, as doing things
incorrectly in this case can often cause dependency loops which are
sometimes fun to debug; perl and openssl were infamous back in the day
for this.
>
> Enterprising users would specify the 'doc' useflag. openssl requires
perl to generate its docs and perl requires openssl for some encryption
stuff. Users would then complain about perl or openssl not building, or
portage getting really pissed at them; the solution being to build
openssl twice, once with USE="-doc" and then build perl, and then
rebuild openssl with USE="doc". This certainly wasn't the only case
where this occurred (see ML thread about shadow and it's dep on some
other package I can't remember, although that was a while back as well).
>
> In conclusion, you need domain knowledge of system packages and
portage behavior to make good choices here ;)

Wow that pasted nastily; hopefully it shows up ok ;)

In any case I'm sure there are some other exceptions but these are the
main ones.
--
gentoo-dev@gentoo.org mailing list

On Sunday 17 December 2006 10:27, Alec Warner wrote:
> If your package is 'not important' meaning it will never be in 'system' for
> any profile, you should not depend on anything in 'system', as stuff in
> system should already be installed in a given (sane) configuration.

Except if the package is fussy on what version it needs.

> If your package may be in 'system' in a given profile, you need to ensure
> your package builds in the proper order, with regards to other system
> packages. The classic example is zlib; if you need zlib to uncompress
> something, then you should put zlib in the deps; that way when someone is
> building say, a stage1, your package will build after zlib, instead of
> before it.

Given your point above, this should only be important as far as bootstrapping
goes. After bootstrapping, "stuff in system should already be installed".
However, 'system' becomes quite an extensive list of packages after enabling
all use flags that didn't begin with 'no'. I've attached the list that
results from my current tree. So are packages such as qt, nvidia-drivers,
courier-imap, samba and jack-audio-connection-kit also part of 'system' or
is 'system' only limited to the profile-defined USE flags at the time of
bootstrapping?

> You have to be careful in deciding what to specify, as doing things
> incorrectly in this case can often cause dependency loops which are
> sometimes fun to debug; perl and openssl were infamous back in the day for
> this.

This stopped applying with recent versions of portage. I'm pretty sure the
current stable version of portage detects circular deps and tries to resolve
them utilizing installed packages but I've lost track of what's made it to
stable and what hasn't. As far as I know, both palidus and pkgcore do or will
also support this, so your point here doesn't hold.

> Enterprising users would specify the 'doc' useflag. openssl requires perl
> to generate its docs and perl requires openssl for some encryption stuff.
[snipped]

This example is not a reason to leave out appropriate dependencies.

I've tried to be objective here so if my viewpoint isn't obvious I'll state
it outright. I think all packages should depend on every package that they
need to build and/or run. Whether this is done explicitly or with
meta-packages, I don't really care. The only reason for not being explicit
with deps is to cater for old sloppy versions of portage. Unless there are
other reasons not stated here?

--
Jason Stubbs

Ciaran McCreesh wrote:
> On Sat, 16 Dec 2006 15:21:36 -0500 Doug Goldstein <cardoe@gentoo.org>
> wrote:
> | > It's quite simple. You don't do it unless you are fully aware of the
> | > consequences. If you have to ask, you aren't fully aware of the
> | > consequences so you mustn't do it.
> | >
> |
> | Which clearly doesn't answer Ryan's question... but hey... that's a
> | Ciaran answer...
>
> No, it answers it perfectly, and far better than the other answers in
> this thread that give an incomplete and inaccurate perspective that
> will encourage people to do the wrong thing.
>

Some people learn by making mistakes ;)
--
gentoo-dev@gentoo.org mailing list

On Sun, 17 Dec 2006 15:10:57 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| I've tried to be objective here so if my viewpoint isn't obvious I'll
| state it outright. I think all packages should depend on every
| package that they need to build and/or run. Whether this is done
| explicitly or with meta-packages, I don't really care. The only
| reason for not being explicit with deps is to cater for old sloppy
| versions of portage. Unless there are other reasons not stated here?

If you mandate that, any package using autotools will need around fifty
new entries in DEPEND.

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster : http://ciaranm.org/show_post.pl?post_id=61

On Sat, 16 Dec 2006 15:21:36 -0500 Doug Goldstein <cardoe@gentoo.org>
wrote:
| > It's quite simple. You don't do it unless you are fully aware of the
| > consequences. If you have to ask, you aren't fully aware of the
| > consequences so you mustn't do it.
| >
|
| Which clearly doesn't answer Ryan's question... but hey... that's a
| Ciaran answer...

No, it answers it perfectly, and far better than the other answers in
this thread that give an incomplete and inaccurate perspective that
will encourage people to do the wrong thing.

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster : http://ciaranm.org/show_post.pl?post_id=61

On Sunday 17 December 2006 16:04, Ciaran McCreesh wrote:
> On Sun, 17 Dec 2006 15:10:57 +0900 Jason Stubbs <jstubbs@gentoo.org>
> wrote:
> | I've tried to be objective here so if my viewpoint isn't obvious I'll
> | state it outright. I think all packages should depend on every
> | package that they need to build and/or run. Whether this is done
> | explicitly or with meta-packages, I don't really care. The only
> | reason for not being explicit with deps is to cater for old sloppy
> | versions of portage. Unless there are other reasons not stated here?
>
> If you mandate that, any package using autotools will need around fifty
> new entries in DEPEND.

There's ways to manage this complexity, such as putting the dependencies into
autotools' RDEPEND (if it can be considered correct) or by using
meta-packages. However, your point is against requiring that packages _must_
specify all system dependencies. While I personally believe that packages
should specify all dependencies, what I'm arguing against is requiring that
packages _must not_ specify any system dependencies.

--
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list

On Sun, 17 Dec 2006 16:41:40 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| On Sunday 17 December 2006 16:04, Ciaran McCreesh wrote:
| > On Sun, 17 Dec 2006 15:10:57 +0900 Jason Stubbs <jstubbs@gentoo.org>
| > wrote:
| > | I've tried to be objective here so if my viewpoint isn't obvious
| > | I'll state it outright. I think all packages should depend on
| > | every package that they need to build and/or run. Whether this is
| > | done explicitly or with meta-packages, I don't really care. The
| > | only reason for not being explicit with deps is to cater for old
| > | sloppy versions of portage. Unless there are other reasons not
| > | stated here?
| >
| > If you mandate that, any package using autotools will need around
| > fifty new entries in DEPEND.
|
| There's ways to manage this complexity, such as putting the
| dependencies into autotools' RDEPEND (if it can be considered
| correct)

That one pulls us back into the lack of distinction between "stuff
needed when compiling against this library" and "stuff this library
needs to run".

| or by using meta-packages.

DEPEND="virtual/c-toolchain" would indeed be nice, but it's a rather
large change...

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster : http://ciaranm.org/show_post.pl?post_id=61

Jason Stubbs wrote:
>
>
> There's ways to manage this complexity, such as putting the dependencies into
> autotools' RDEPEND (if it can be considered correct) or by using
> meta-packages. However, your point is against requiring that packages _must_
> specify all system dependencies. While I personally believe that packages
> should specify all dependencies, what I'm arguing against is requiring that
> packages _must not_ specify any system dependencies.
>
> --
> Jason Stubbs

I agree with your personal belief, however I also find it unmaintainable
in the current system (metapackages in their current form
non-withstanding as I don't think they are a great solution, merely duct
tape if you will, but that is another discussion entirely).

There is no benefit for me as a package maintainer to dep on a system
package unless there is an existing problem. From a maintainer POV it's
extra work and extra writing to keep the deps up to date. Also there is
the whole thought of what to list? Do I list only glibc versions that I
know work? gcc versions that I know compile my code? Where does the
line get drawn? What is the point of depending on certain elements if
say, they are already a dependency of $PACKAGE_MANAGER? It is not
pragmatic for a distribution to do so IMHO, 'technically correct' or not.

A few use cases that would go against this involve people doing odd
things like emerging a bunch of stuff and then unmerging a critical
system package (say, ncurses); since my program happened to depend on
ncurses anyway it would 'fix' the problem automatically for the user
instead of dying with no ncurses. Of course this use case could be
handled another way; by having portage make sure that packages listed in
'system' are installed. While I am a fan of the 'fix it automatically
in DEPEND' way here; the use case is rather...convenient. Unmerging
many things in system either break portage, or won't affect anything (oh
no I unmerged virtual/editor!)

So yeah, in conclusion; too much work, fix it when it's reported broken
seems like a decent (pragmatic) policy to me. If/When it becomes easy
to list stuff (package sets or something, please not metapackages in
their current form) then I'd be much more interested in implementing it.

As an aside, If you are unsure in a given situation feel free to ask
someone about it. Worse case you (put an extra dep in|leave out a dep);
both are easily repairable.
--
gentoo-dev@gentoo.org mailing list

On Sun, 17 Dec 2006 03:14:57 -0500 Alec Warner <antarus@gentoo.org>
wrote:
| As an aside, If you are unsure in a given situation feel free to ask
| someone about it. Worse case you (put an extra dep in|leave out a
| dep); both are easily repairable.

No, worst case you go and break anyone trying to do a clean install,
and then a reviewer for a large magazine happens to try to do a new
install that day and gives up because of the error.

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster : http://ciaranm.org/show_post.pl?post_id=61

On Mon, 18 Dec 2006 07:28:25 +0000 Steve Long
<slong@rathaus.eclipse.co.uk> wrote:
| Ciaran McCreesh wrote:
| > That one pulls us back into the lack of distinction between "stuff
| > needed when compiling against this library" and "stuff this library
| > needs to run".
|
| Wouldn't your c-toolchain or a compiler eg for PERL or Java do?

You're missing the distinction. The easy example, but not the best, is
pkg-config: many libraries must be used via pkg-config, so they need to
RDEPEND upon it to avoid breaking binary packages. However, they don't
actually require it at runtime. The other option, which is just about
doable in this one particular case, is to make any package that uses a
library that uses pkg-config DEPEND upon pkg-config.

| > | or by using meta-packages.
| >
| > DEPEND="virtual/c-toolchain" would indeed be nice, but it's a rather
| > large change...
| >
| How so? Isn't it simply a new meta?

And an entire tree to update before it becomes meaningful.

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster : http://ciaranm.org/show_post.pl?post_id=61

On Wed, 20 Dec 2006 04:59:58 +0000 Steve Long
<slong@rathaus.eclipse.co.uk> wrote:
| How serious an issue is it in terms of deps on sys pkgs?

Very. It means we can't realistically handle packages that, by using
autotools, depend upon the fifty odd system packages that are used by
autotools-generated code.

| > | > DEPEND="virtual/c-toolchain" would indeed be nice, but it's a
| > | > rather large change...
| > | >
| > | How so? Isn't it simply a new meta?
| >
| > And an entire tree to update before it becomes meaningful.
| >
| Sure, but the changes can propagate thru as people update their
| ebuilds, no?

The tricky part then is figuring out whether something doesn't dep upon
c-compiler because it doesn't need one or because the ebuilds haven't
been updated.

--
Ciaran McCreesh
Mail : ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster : http://ciaranm.org/show_post.pl?post_id=61

Steve Long wrote:
> Ciaran McCreesh wrote:
>> Steve Long wrote:
>> | How serious an issue is it in terms of deps on sys pkgs?
>>
>> Very. It means we can't realistically handle packages that, by using
>> autotools, depend upon the fifty odd system packages that are used by
>> autotools-generated code.
>>
>> | > | > DEPEND="virtual/c-toolchain" would indeed be nice, but it's a
>> | > | > rather large change...
>> | > | >
>> | > | How so? Isn't it simply a new meta?
>> | >
>> | > And an entire tree to update before it becomes meaningful.
>> | >
>> | Sure, but the changes can propagate thru as people update their
>> | ebuilds, no?
>>
>> The tricky part then is figuring out whether something doesn't dep upon
>> c-compiler because it doesn't need one or because the ebuilds haven't
>> been updated.
>>
> I'm out of my depth here- I can't see where that would be a problem?
>

Er, his point being that if you don't do the upgrade all at once, you
have two classes of package.

1. Packages that don't require C-compiler
2. Packages that don't yet depend upon C-compiler

When doing the upgrade over a period of time the two classes of package
become indistinguishable. Does Foo not need a C compiler, or has it
just not gotten updated yet, it's impossible to tell without looking, so
it's very difficult for people to report 'problem packages' because they
have to unpack and examine the package every time (at worst).

--
gentoo-dev@gentoo.org mailing list

Steve Long wrote:
> Alec Warner wrote:
>> Er, his point being that if you don't do the upgrade all at once, you
>> have two classes of package.
>>
>> 1. Packages that don't require C-compiler
>> 2. Packages that don't yet depend upon C-compiler
>>
>> When doing the upgrade over a period of time the two classes of package
>> become indistinguishable. Does Foo not need a C compiler, or has it
>> just not gotten updated yet, it's impossible to tell without looking, so
>> it's very difficult for people to report 'problem packages' because they
>> have to unpack and examine the package every time (at worst).
>>
> I understand that there'd be two types of pkg in the tree; what I don't get
> is why that is such a problem. Excuse my missing something obvious. What do
> you mean by a `problem package' in this context?

A problem package would be one that does not need a C compiler. It can't
be distinguished from the one which was not yet changed to depend on C.

The problem here is that one can not say when the whole tree is updated
to the new standard, because for the packages which were not touched, it
could mean that they needed no change or that they were not looked at yet.

A solution to distinguish the two categories is to mark the packages
which were "checked", so you know:
1. If it's checked and doesn't depend on cc -> category 1
2. If it's not checked and doesn't depend on cc -> category 2

Then, when all packages are checked, the tree is upgraded.

Regards,

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

Steve Long wrote:
> Robert Buchholz wrote:
>> The problem here is that one can not say when the whole tree is updated
>> to the new standard, because for the packages which were not touched, it
>> could mean that they needed no change or that they were not looked at yet.
> I can understand that as a maintenance issue. My query is whether having two
> different types of pkg would effect users in any way.

You're right, it would not be a problem for usability.


>> A solution to distinguish the two categories is to mark the packages
>> which were "checked", so you know:
>> 1. If it's checked and doesn't depend on cc -> category 1
>> 2. If it's not checked and doesn't depend on cc -> category 2
>>
>> Then, when all packages are checked, the tree is upgraded.
>>
> Sure, that makes sense. It sounds a heckuva lot like a database ;)
>
> Minor point- how can you tell in cat 2 that it definitely does not need a C
> compiler if it hasn't been checked? I'm guessing you were tired :) In any
> event in terms of maintenance, we'd need a tri-state: unchecked, checked
> and needs compiling, checked and doesn't (eg scripts).

No, no. I did not mean that "category 2" does not need a C compiler. I
referred to Alec's mail which had "2. Packages that don't yet depend
upon C-compiler".
As for the state problem, when saving "checked" and "unchecked" as a
package's metadata, you will get the other properties (needs cc, needs
<insert system dep>) out of its DEPEND.


> In terms of maintaining the metadata, am I right in thinking it's all just
> kept within the text files in the tree?

Since the tree itself is the best database of the packages available,
anything else would be a lot more overhead.

But I had the impression the idea was discarded anyway. So I should
focus my thoughts somewhere else :-)


Ciao,

Robert

--
gentoo-dev@gentoo.org mailing list