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
signature.asc
Description: This is a digitally signed message part.
