[gentoo-portage-dev] ideas for portageNG

[leon breedt]

hi

i just found out about the plan for the portageNG project, and i have
some ideas after reading the beginnings of your specification. all
mixed, and a bit long, please bear with me.

METADATA
--------

this is probably one of the most important things as i see it.
distributing, patching, compiling source files, is relatively easy to
implement, but its all useless if its not easy to modify/extend the
actions that will accomplish this.

and since those actions will depend in a large part on the metadata they
have available, its critical to ensure that as much information as could
be required is available to those actions (implemented by plugins).

as i see it, this is a nice progression for metadata to take (i've
stolen this concept of uPM (http://u-OS.org):

you start with your base "specification" file (i.e. .ebuild); residing
in /usr/portage or somewhere else. this forms the start of your
metadata. as you progress through the various stages of fetching,
unpacking, compiling, merging, and so forth, additional things are added
to your collection of metadata for the package. at no point should any
metadata generated by an action be lost, if it could be useful to a
subsequent action.

i fully agree with the decision to seperate the stepped metadata from
the static.

i don't know if seperate files would be desirable though.
i'd rather go for the approach where you still have one "specification"
for the package, with various sections implementing the "stepped"
functionality.

i'd love the ability to make a "step" run through a filter though.
imagine: using Python or Perl inside your spec file to do the various
desired actions. and this Python code having full access to the current
set of metadata for the package, and being able to modify it.

if you allow that, then you could automagically make a fair set of
convenience libraries available to the code. this could increase
performance somewhat, as well. i see the main benefit though, being able
to execute in-process with the emerge process.

i'd also at this early time like to sugggest that the base
"specification" file be a custom format, and NOT XML.

keep all machine-generated metadata, and everything in the backend DB
storage after this first file as XML, definitely, but the
human-maintained file should not be XML, but completely customized to
the Portage metadata needs.

let the maintainer wade through the minimum amount of boilerplate crap,
to improve maintenance scalability to 100s of thousands of packages,
please :)



CHANGE TRIGGERS (OR, LET US AND THE USER DO CREATIVE THINGS WHEN SYSTEM
CHANGES OCCUR)
------------------------------------------------------------------------

another idea, in part from uPM, and in part from Linux-hotplug, is to
support rule-based actions when Portage events occur. 

- the system defines a rule that will fire when installation/removal of
files matching a regex occurs. uses? imagine files that need to be
registered with some central database (i.e old style X font files). when
a package then installs files matching a regex or a specific dir prefix,
for example, magically the fonts get registered, WITHOUT REQUIRING ANY
ACTION BY THE PACKAGE. i suspect this kind of behaviour can increase
maintainability of ebuilds significantly. think of all the actions you
now don't have to do explicitly. auto-prelinking!

- the user defines a rule: for example, if i have a server in the field,
and i want to know when changes occur, like, a package is upgraded,
maybe i want that to propagate out via email.

for this to work well though, the metadata story from above will have to
be well thrashed out so that all the necessary stuff is available to the
trigger. so, for example, if a particular package is NOT suited to this
kind of auto-stuff (i.e. prelinking), you have that metadata available,
and can exclude it from processing. either by some central database of
exclusions, or perhaps a tag in its metadata saying it doesn't play well
with prelink, for example.


BUILD TRIGGERS
--------------

roughly the same principle as for triggers can be applied to the actions
that participate in cobbling together a package.

i think it makes sense to seperate the action of building (which i
define to mean the whole fetch, unpack, compile, merge process), with
the action of actually doing something that changes the target system.

however, i would differentiate between actions which occur when the
system is modified (triggers) and actions which occur when a package is
being put together, and keep them completely seperate.

why? because you typically don't want people to mess with actions that
assemble the package, they're system-level actions we've defined to
implement the build process, and we're just really re-using roughly the
same concept as for triggers to make Portage flexible and its
maintainence easy, no?

they should be configurable via big knobs in /etc, though. i.e. if GnuPG
verification was implemented as a system-level extension to, say, the
pre-UNPACK/post-FETCH stages, maybe you want to turn it off. but you, as
user, shouldn't modify the extensions available for stages which affect
package assembly, otherwise, all bets are off as to Portage working.

once again, metadata passed to these extensions should be complete.




well, thats my brain dump for now. hopefully it wasn't too long-winded.
what do you think?

leon


--
gentoo-portage-dev@g.o mailing list