Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Mar 2008 21:14:58 -0400
From:      "Aryeh M. Friedman" <aryeh.friedman@gmail.com>
To:        Ivan Voras <ivoras@freebsd.org>
Cc:        freebsd-ports@freebsd.org
Subject:   Re: SoC Project: Ports 2.0 engine
Message-ID:  <47E85212.1070905@gmail.com>
In-Reply-To: <fs953n$gg5$1@ger.gmane.org>
References:  <47E30FB4.1000205@gmail.com> <fs953n$gg5$1@ger.gmane.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Ivan Voras wrote:
> Aryeh M. Friedman wrote:
>> School ate any free time I had to work on ports 2.0.   For this 
>> reason I would like to find some way to make it a Summer of Code 
>> project.  Kip Macy has provisionally agreed to mentor it if a) it is 
>> approved by Google and FreeBSD, b) No one more qualified steps forward.
>>
>> Project goals (SoC portion):
>>
>>    1. Impliment beta quality version of the engine (see "Recursive 
>> Make Considered Harmful" for main points)
>
> I can't find the post with this title, but I think I get what you mean :)

http://aegis.sourceforge.net/auug97.pdf
>
>>    2. Use the engine to build xorg and all ports it depends on
>>
>>    3. Creation of compatibility layer
>>
>> What do people think and should I proceed with submitting a 
>> application to Google?
>
> Go for it :)
>
> I'd like to suggest two of the major features that a new ports system 
> should have:
>
> - reliability (almost in the database "ACID" sense; for example that 
> no half-registered packages are created by issuing Ctrl-C in a 
> critical moment)
> - parallel builds of as much as possible; at least parallel builds of 
> independent dependencies and if possible also of ports themselves 
> (probably by adding an opt-in flag in Makefile to signal if the port 
> supports "make -j" for its build phase).

These two items are being handled in a different (but hopefully 
cordinated) project http://wiki.freebsd.org/PortsToDo

>
> The first one can be solved by rolling your own system which carefully 
> juggles atomic operations and locks or by using an already present 
> solution like sqlite.
>
If we limit it only to top level stuff then it is not that bad I 
think.... if you want more details I can forward some private 
conversation between me and the person working on the above project



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47E85212.1070905>