duration of the ports freeze

[Josh Paetzel]

On Saturday 01 December 2007 04:49:23 pm Aryeh M. Friedman wrote:
> Peter Jeremy wrote:
> > On Sat, Dec 01, 2007 at 04:10:14PM -0500, Aryeh M. Friedman wrote:
> >> This is due to thinking of the port system as one would of as say
> >> make(1) namely a multistage transaction vs. one big atomic
> >> transaction.   Doing first makes each port responible for most it's
> >> knowledge and thus open to inconsistencies and the other makes so the
> >> port is nothing but a node in a graph with the edges holding most of
> >> the knowledge instead of the nodes.
> >
> > You continue to complain that the current dependency system is broken
> > but you have yet to provide an alternative.
>
> Right off the top my head a simple DFS or topo sort with approriate
> knowledge in the edges would suffice.
>
> >> If there was a universal way of handling stuff as recommended in
> >> Miller97 and most decent algorithm books.
> >
> > You also regularly references to Aegis - again with no explanation as
> > to what problem Aegis would solve and how it would solve it.  I recall
> > hearing Peter Miller present his paper at AUUG'97 and I know I was
> > interested enough at the time to install and experiment with Aegis but
> > (for reasons I don't recall any longer), I have since reverted to make.
>
> First of all he was refering to cook not aegis (aegis is his
> alternative to CVS).   I stopped using also because the scripting
> language is really badlly layed out semantically (basically he tried
> to get a functional language into the syntax of an imparative one).
> Other then that it is actual quite good.  The altenrative is unlike
> make which does basically this:
>
> select some target
>     check all dependancies on the target recursivally using this algorithm
>     if all depends are uptodate bring the target up to date
>
> This has the weaknesses offered in the paper and other large recursive
> single node graph processors... yes they can solve a maze but only by
> trial and error instead of attempting essentially an all paths
> solution before selecting the optimal one (namely a well made cook
> project guarantees the spanning tree in all cases where make almost
> guarantees a non-span tree for any non-trivial source tree)... a
> careful read of Rivest-Korman-et. al. chapter on graphs will show the
> same conculsion... for a quick and dirty guide on cook read the
> tutorial I wrote on the cook site (Peter's main site not the aegis one)

I remember once upon a time reading some advice being handed out to potential 
contributors to a large project.  It was something along the lines of:

"You may have heard of good ideas, been taught them in comp-sci class by a 
research professor, or read about them in a book, but if you don't have 
practical working knowledge of a working implimentation of them <heavy 
paraphrasing> please don't bother trying to wedge them in to our project 
</heavy paraphrasing>"

The ports tree was never intended to scale to 18,000 apps in it, but the 
reality of the situation is that it has....and so has the infrastructure to 
support it.  Does it have some weaknesses and deficiencies?  Absolutely.  
Does it have some amazing strengths?  Absolutely.

I've been using FreeBSD since 1995 on my desktop, and since 1996 on servers.  
Maybe my practices with ports are influenced by the deficiencies in the tools 
or maybe they just make sense, but I don't really use the ports tree for 
anything but make package and make package-recursive anymore.   I 
don't 'upgrade' in the traditional way anymore either.  Services run in 
jails, jail images are created with a list of apps, installed from prebuilt 
packages built on a build host.  When it comes time to 'upgrade' I unpack the 
new jail with the new batch of packages and cut over the firewall rules 
directing traffic in to the jail. (jails run on loopback IPs)

I've never found a need for portupgrade and friends, in my opinion those tools 
are a siren song for getting in to an unsupported combination.  The typical 
usage goes.......

1) start with a port tree from date A
2) install a ton of ports
3) cvsup/csup/portsnap your ports tree
4) install more ports and/or run portupgrade on parts of your installed ports.

At least with packages it complains if you have a dependancy installed that 
doesn't match what the package was built with.  Using ports improperly as 
described above leaves you with apps build against dependancies they 
shouldn't be.  eg: today's foomatic built against who knows what version of 
libfoomatic.

If you wanted to do something practical, work on improving dependancy and 
conflict handling in the current ports tree.  Asserting that you are going to 
rewrite the entire package management system for FreeBSD puts me in 
to "believe it when I see it mode" and makes me think you don't realize how 
much work it would be.

Anyways, 3am and sleep beckons.

-- 
Thanks,

Josh Paetzel

PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20071203/4c2e8894/attachment.pgp