Re: [gentoo-dev] RFC - Gentoo on the Lab

[Kristian Benoit]

On Mon, 2005-08-22 at 21:41 +0100, Stephen Bennett wrote:
> On Mon, 22 Aug 2005 13:49:14 -0400
> Kristian Benoit <kbenoit@×××××××.com> wrote:
>
> > I do agree with that, portage probably need a rewrite/better
> > modularization anyway. There is/was a project called portage-ng () you
> > might want to have a look at. I did a little in that direction
> > recently, and it seems that there is not too many people working on
> > it since drobbins left, but you can contact Pieter
> > (pvdabeel@g.o). I might get on that too at some point in the
> > future too.
>
> portage-ng is dead. There is a rewrite going on, but it'll take a while
> to get anywhere near usable.

Here is my recent communication with Pieter:

On Sat, 2005-08-13 at 21:59 +0200, Pieter Van den Abeele wrote: 
> On 13 Aug 2005, at 19:16, Kristian Benoit wrote:
>
> > I've heard that you might be the last to know something about
> > portage-ng. What's the actual status,
>
> Here's what I've done so far:
>
> I've build upon Andreas' Zeller idea of using Smolka's feature logic
> for software configuration management. Zeller's approach was ok for
> determining consistency/inconsistency of software configurations. In
> his phd thesis he described the algorithm involved and discussed time
> complexity (which goes to NP if you allow for quantification). My
> impression after implementing his idea was that for automated
> construction there were a few things that were lacking, and some
> things were incorrect. I revisited Zellers feature logic, and ended
> up with a clean implementation of a declarative language which has
> some very desirable properties for automated software construction.
> I'd say my approach is closer to the spirit of Smolka's feature logic
> than Zellers approach. My non-destructive feature unification has a
> worst case time complexity of O(n x m) where n is the length of the
> feature term describing your system, and m is the length of the
> feature term describing the component to be added. In practice
> performance is very good. An emerge --vp --emptytree kde with the
> regular portage takes about 55 seconds on my Open Desktop Workstation
> and produces a list of 200 packages. A similar action using my
> implementation:
>
> =====================================================================
> Total time: 14.55 seconds
> =====================================================================
> Predicate                       Box Entries =    Calls+Redos     Time
> =====================================================================
> vunify/4                            341,900 =  341,900+0        72.6%
> $garbage_collect/1                      326 =      326+0        13.6%
> lists:append/3                      684,320 =  684,320+0         4.0%
> genterm/2                               520 =      520+0         3.9%
> hunify/4                                520 =      520+0         3.3%
> is/2                                342,420 =  342,420+0         1.8%
>  >/2                                 342,160 =  342,160+0         0.8%
> buildsystem/2                             1 =        1+0         0.0%
> val/3                                 5,200 =    5,200+0         0.0%
> unify/3                                 260 =      260+0         0.0%
>
> % 9,531,861 inferences, 13.96 CPU in 14.55 seconds (96% CPU, 682798
> Lips)
>
> The search space is kept as small as possible because I've introduced
> lazy feature evaluation and both multi valued and open features.
> Those concepts are missing in Zellers approach. Comparing current
> portage and my implementation performance-wise is difficult. In
> general mine is faster, but current portage doesn't use sql either.
> What is for sure is that mine allows you to express various
> constraints. You can prevent a dependency from being built with a
> specific use flag. My implementation automatically solves 'blockers'.
> Circular dependencies are also solved correctly. For instance, if you
> want to install unixodbc with the qt use flag enabled and you want to
> install qt wit the unixodbc use flag enabled, my portage knows that
> it needs to:
>
> emerge unixodbc without qt
> emerge qt with unixodbc
> remerge unixodbc with qt support
>
> So it makes revdep-rebuild unnecessary basically.
>
>
> Once I was done implementing this new declarative language in which
> for instance ebuild concepts can be easily expressed (but also rpm,
> deb, fink, darwinports). I implemented a knowledge base in which
> those feature terms can be stored/looked up efficiently. I used an
> odbc bridge design pattern and have tested the thing with postgresql/
> mysql and sqlite. I've also implemented a DCG parser which parses
> ebuilds (no more having to start a bash process for each ebuild like
> current portage does) and converts it to feature logic representation
> very efficiently. One of the things I'm doing now is finishing up the
> documentation and experimenting with an RDF based system for
> 'ebuildcasting'. The idea is that users who write ebuilds could
> "ebuildcast" it like some people podcast their own radio shows. The
> knowledge base can be subscribed to several sources (basically the
> idea of portage overlays but combined with some ideas from the
> semantic web).
>
>
> > can we see the code,
>
> yes, the first release (and all releases after that) will be GPL.
>
>
> > do you think there is still a hope ?
>
> As for me finishing this and doing something with it, yes.
>
>
> > Anyway, I'd like to learn what there is to learn about it and perhaps
> > help to get it restarted.
>
> For your convenience I've put some interesting papers online on
> http://www.metadistribution.org/seminar-tinf/
>
> I'd love to discuss the idea of feature logic with you while I'm
> finishing things up.
>
> Pieter
>
>
> > thank for any info.
> >
> > Krisitian

-- 
gentoo-dev@g.o mailing list