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

[Kristian Benoit <kbenoit@opersys.com>]

On Mon, 2005-08-22 at 21:41 +0100, Stephen Bennett wrote:
> On Mon, 22 Aug 2005 13:49:14 -0400
> Kristian Benoit <kbenoit@opersys.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@gentoo.org). 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@gentoo.org mailing list