Santiago M. Mola wrote:
On Tue, Jun 10, 2008 at 10:20 PM, Federico Ferri <[EMAIL PROTECTED]> wrote:
The so-called shebang; very good in my opinion!
Works very well for true shell scripts. why it can't work for ebuilds?
This option was already discussed when GLEP 55 was proposed, and in my
opinion it's totally discarded. The concept of shebang doesn't apply
here at all. Plus /usr/bin/ebuild is a binary provided by portage
which has nothing to do with the process of sourcing ebuilds nor even
with the internals of portage (not to speak of other package
managers).
I had thought of this option as well - I agree that it has a lot of
issues. I agree that ebuild wouldn't be the right tool, but in the
right framework I could see how something like this might work.
Here is how a portage tree might be handled by a future package manager
that uses shebangs to implement any number of EAPIs that have almost no
restrictions on file contents other than the shebang:
When new "ebuilds" are synced into the repository, they are executed.
If the interpreter doesn't exist, then it is an unsupported EAPI and the
failure is silently ignored (or logged or whatever). If the interpreter
does exist it will interpret the file properly - perhaps using a EAPI
command-line option from the shebang line or whatever is appropriate for
that EAPI which the interpreter obviously understands. If the
interpreter determines that the file uses an EAPI it doesn't know, it
aborts execution and skips the package. That makes the scheme always
backwards compatible (well, at least until the switch to this approach -
current package managers wouldn't be compatible).
When the new ebuild is executed, it will call appropriate functions to
register itself into the local repository. That registration might
include callbacks of some kind or whatever - the whole way the ebuild
works could vary by EAPI - since the interpreter used by the EAPI could
change. The only restriction for compatibility is a standard shebang
line.
Each ebuild would only be executed upon a change when it is synced, so
the overhead isn't huge. At that point all the data is stored in a
local cache and the ebuilds themselves don't get touched until they are
installed. Installation will work in an EAPI-dependent way - perhaps by
executing the ebuild with a particular parameter or environment setting
or whatever. The package manager will know since it has already been
established that this is a supported EAPI by the fact that the ebuild
got processed when it was synced in.
This kind of system also makes it easy to support some scenarios that
are currently hard:
1. Download a random ebuild off the internet and want to add it to your
repository? Rather than having to put it in a local portage tree you
could just execute it from anywhere and it would register itself in its
present location - and act like any other package in the tree.
2. No need for utilities like ebuild to manipulate the install process
- instead just execute the ebuild with the appropriate parameters or
whatever to get it to do the install process.
On the other hand, this is a big change from the present, and I'm not
convinced that it will actually be a big improvement over some of the
other EAPI ideas being floated around. However, it is a
potentially-neat idea...
--
gentoo-dev@lists.gentoo.org mailing list
