Date: Mon, 03 Dec 2007 04:18:34 -0500 From: "Aryeh M. Friedman" <aryeh.friedman@gmail.com> To: Josh Paetzel <josh@tcbug.org> Cc: Peter Jeremy <peterjeremy@optushome.com.au>, freebsd-ports@freebsd.org Subject: Re: duration of the ports freeze Message-ID: <4753C9EA.4060705@gmail.com> In-Reply-To: <200712030302.51908.josh@tcbug.org> References: <20071201204245.GA57218@lpthe.jussieu.fr> <20071201221533.GU50167@server.vk2pj.dyndns.org> <4751E4F3.9010603@gmail.com> <200712030302.51908.josh@tcbug.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Josh Paetzel wrote: > 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>" I have practical knowledge here in working with different dependency management systems (which is essentially what the ports system is)... now that being said much of it is based on seeing how different people have solved the problems raised by the methods you site as being "invalid" > > 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. That is the purpose of the survey I sent out to start to uncover what exactly the strengths and weaknesses are and decide if the weaknesses are sufficent to warrent any kind of re-engineering. > > 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) This only works for a large test bed and not totally useful for a causal user. > > 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. That is one of the goals of the over all project but while we are at we should examine the system as a whole since adding to a critically flawed system just postpones the issue but a ground re-write of a non-critically flawed one a waste of time and asking for problems.... As too complexity just because the details are messy (as will be case no matter what) there can still be a very simple conceptual framework such as the 4 layer UNIX model of OS's. > > Anyways, 3am and sleep beckons. > - -- Aryeh M. Friedman FloSoft Systems Developer, not business, friendly http://www.flosoft-systems.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHU8nq358R5LPuPvsRAlz7AJ9XeSzPZiafWNkMkiIAzDQC0UZYpACdEGhc N9oKU5FIkpN5hAB4/4/Liwo= =VF9U -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4753C9EA.4060705>