Date: Mon, 3 Dec 2007 03:02:47 -0600 From: Josh Paetzel <josh@tcbug.org> To: freebsd-ports@freebsd.org Cc: Peter Jeremy <peterjeremy@optushome.com.au>, "Aryeh M. Friedman" <aryeh.friedman@gmail.com> Subject: Re: duration of the ports freeze Message-ID: <200712030302.51908.josh@tcbug.org> In-Reply-To: <4751E4F3.9010603@gmail.com> References: <20071201204245.GA57218@lpthe.jussieu.fr> <20071201221533.GU50167@server.vk2pj.dyndns.org> <4751E4F3.9010603@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1500697.1YBOqCxtzV Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 potenti= al=20 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= =20 research professor, or read about them in a book, but if you don't have=20 practical working knowledge of a working implimentation of them <heavy=20 paraphrasing> please don't bother trying to wedge them in to our project=20 </heavy paraphrasing>" The ports tree was never intended to scale to 18,000 apps in it, but the=20 reality of the situation is that it has....and so has the infrastructure to= =20 support it. Does it have some weaknesses and deficiencies? Absolutely. =20 Does it have some amazing strengths? Absolutely. I've been using FreeBSD since 1995 on my desktop, and since 1996 on servers= =2E =20 Maybe my practices with ports are influenced by the deficiencies in the too= ls=20 or maybe they just make sense, but I don't really use the ports tree for=20 anything but make package and make package-recursive anymore. I=20 don't 'upgrade' in the traditional way anymore either. Services run in=20 jails, jail images are created with a list of apps, installed from prebuilt= =20 packages built on a build host. When it comes time to 'upgrade' I unpack t= he=20 new jail with the new batch of packages and cut over the firewall rules=20 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 to= ols=20 are a siren song for getting in to an unsupported combination. The typical= =20 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 por= ts. At least with packages it complains if you have a dependancy installed that= =20 doesn't match what the package was built with. Using ports improperly as=20 described above leaves you with apps build against dependancies they=20 shouldn't be. eg: today's foomatic built against who knows what version of= =20 libfoomatic. If you wanted to do something practical, work on improving dependancy and=20 conflict handling in the current ports tree. Asserting that you are going = to=20 rewrite the entire package management system for FreeBSD puts me in=20 to "believe it when I see it mode" and makes me think you don't realize how= =20 much work it would be. Anyways, 3am and sleep beckons. =2D-=20 Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB --nextPart1500697.1YBOqCxtzV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHU8Y7JvkB8SevrssRAmCbAKCKKp4Jy+NHDMS8ePPrGBmsMukIqACfXn7n brdUF1yVdDBI0zc6sTQ62mM= =Bq96 -----END PGP SIGNATURE----- --nextPart1500697.1YBOqCxtzV--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200712030302.51908.josh>