Quoting VulK <[email protected]>:
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
