On Mon, 2005-08-22 at 21:41 +0100, Stephen Bennett wrote: > On Mon, 22 Aug 2005 13:49:14 -0400 > Kristian Benoit <[EMAIL PROTECTED]> 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 > > ([EMAIL PROTECTED]). 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
