Re: [gentoo-alt] branched prefix chaining

[Markus Duft]

On Wed, 2009-07-08 at 00:58 +0200, Viktor Griph wrote:
> Hi,
>

Hey!

Good to hear that somebody (apart from me/us) is playing with this :) i
will try and (as the author of the patch) add some useful comments ;)

> I've just started playing with the prefix-chaining abilities, and I
> find it quite useful. However what is the reason for not allowing
> multiple read only prefixes in a chained prefix? I'm currently working
> with a setup where the policy is that each application should be
> installed in it's own prefix, which means that if there should be only
> one log chain of prefixes it would possible get very long, whereas if
> it were branching it could be kept at a relatively low depth.

The reason for not allowing multiple prefixes in one level of the chain
is to keep things simple in the first place. There may be problems when
the same package can be found in multiple parent prefixes on the same
tier, as portage would need to choose one of them to use, but it won't
be guaranteed that that version will be really linked, since at build
time, all of them would be reachable by the compiler/linker (it of
course needs to know all of the parents). (ATTENTION: the above applies
only if inheriting RDEPENDS, not if only DEPENDS are inherited).

Also I couldn't think of a real use case where this would be absolutely
necessary. i admit that I'm slightly influenced by the use case here at
our company: we have one "system prefix", building upon that we have a
"framework prefix" and again, building upon that the "application
prefix".
the "system prefix" is shared upon all "framework prefixes". each
"framework prefix" is used by multiple "application prefixed" each of
them containing one final application. So we're perfect with a one
dimensional chain. (the "one dimensional" is from the POV of each
involved prefix, of course. looking at the whole picture we have this:

      s1
      |
   +--+--+
  f1  f2 f3
   |  |  +--+
   |  |  |  |
  a1  a2 a3 a4

so, none of the applications (a1-a4) know of each other. those prefixes
are unrelated and each application has a one dimensional direct chain to
s1).

could you describe your current and desired setup a little closer? would
be interesting... :)

>
> I'm tempted to try to change this myself, but before I do I'd like to
> get some input on why it was made the way it is. A few things I've
> noticed about the chaining prefixes as they are now:
> 1) the prefixes are linked in with no particular order in portage, but
> follows the chain in /etc/profile. I'm not sure if the portage order
> makes any difference as I've very little experience with this yet, but
> I think that those prefixes should be included in order as well.

what do you mean by "linked in with no particular order in portage"?
since the chaining is a strictly one dimensional chain (at least
ATM :)), the ordering is implicit. the top most prefix (it may or may
not contain it's own portage btw.) reads it's config, finds a readonly
prefix, reads that one's config, finds another one, etc. this way the
whole chain of configurations is built up during portage startup. hope
that was clear...?

>
> My idea on how branching prefixes could be done is similar to how the
> chaining prefixes work now, but with a little extra logic required to
> not include the same prefix more than once.

so you want something like this?:

         a
         |
      +--+--+
      b  c  d
      +--+  |
         e  |
         +--+
         f

where f inherits from *all* prefixes? i guess there is a reason why
modern OO languages forbid multiple inheritance - it's a headache! :)
And still those languages are quite popular, and seemingly don't lack
any obvious big features. one of them is java, so lack of multiple
inheritance can't really hurt, can it?

> I think that changing the current inclusion to a breath first tree
> traversal with marking of already visited prefixes should work for the
> portage tree. When it comes to the environment I really don't see why
> it is made from /etc/profile recursively currently. Wouldn't it make
> more sence to have env-update simply source the profile.env of the
> parent prefix, and poin it with the env.d at the current level, and
> possible include a utility for recursively doing env-update in several
> prefix-chains if needed. At least that's the way I think would work
> the best when it comes to multiple readonly prefixes. Is there any
> reason why this wouldn't work? (Other than the fact that this would be
> a depth first inclusion instead of a breath first inclusion as I
> suggested for portage, if the order matters.)

phew. IIRC it took me a few days to get that right in my head only,
without implementing it (implementation was done in a few minutes
actually) - thinking back to the problems i faced, the only one that
jumps to my mind right now was that a patched env-update would not
suffice because any of the parent prefix can change without us getting
any note of it. (however of course there are more problems of that kind,
like the parent prefix not knowing us, so he won't prevent unmerging
libraries the child prefix needs).

also, changing the type of inheritance (RDEPEND, DEPEND, PDEPEND) would
require an env-update call - one thing that for sure is forgotten at
least half of the time.

if more comes to my mind, i will tell you :)

i'd be happy to discuss my points, if you find them void ;)

Cheers, Markus

>
>
> Viktor Griph
>