Quoting VulK <etn45p4m@...>:

> Hi,
> Thank you for the explanation: I kind of guessed that some part of sage were
> omitted to adapt the two packaging system but your explanation gave me the
> details I was missing.
> As you said the combinat queue is/should be a real mess of continuous
> updates (at least this is what I was told) so I am not entirely sure how well
> an e-build would perform, in case you decide to spend some time on it I will
> gladly be a guinea pig for testing it out.
> I do not understand sage package system in details so my request may just be
> stupid but is it possible to produce separate ebuilds for the different part
> of sage that are now stripped? If not for all of those can this be 
> done for the
> various packages in $SAGE_ROOT/devel ? If an e-build is not feasible, can
> USE flags be used to select which extensions to include at compile time?
>
The details are a bit long to explain but everything provided by sage is
currently split. Technically what is missing is some scripts from the spkg
sage_scripts (provided by our sage-baselayout ebuild). Most of the files in
$SAGE_LOCAL/bin of a vanilla install that starts with sage are provided 
by this
spkg. And we omit a lot of them, some are already installed only on use flag
request. We could add more if it was useful and feasible from a package
management perspective.

I must say that talking with sage-developers interested in sage installed with
portage there is a possibility that some stuff may come back in some form once
we figured it out. Something like sage -combinat creates a new sage branch.
There is a possibility that we could allow such a branch to be created 
inside a
user account (not system wide) and allow its use. But that's still some 
way off
on my map. In fact it may come as a surprise to my fellow sage-on-gentoo devs.

Francois