Date: Sat, 13 Jul 2002 05:14:33 +0100 (BST) From: Mark Valentine <mark@thuvia.demon.co.uk> To: Terry Lambert <tlambert2@mindspring.com> Cc: jos@catnook.com, arch@freebsd.org Subject: Re: Package system flaws? Message-ID: <200207130414.g6D4EXo6029385@dotar.thuvia.org> In-Reply-To: Terry Lambert's message of Jul 12, 8:17pm
next in thread | raw e-mail | index | archive | help
> From: Terry Lambert <tlambert2@mindspring.com> > Date: Fri 12 Jul, 2002 > Subject: Re: Package system flaws? > Mark Valentine wrote: > > Um, you didn't read down to the ``Delegations'' section... > > I read it. It is not enforced. There is an escape mechanism > through human serialization, and, given his organization, you > would have to be insane not to take advantage of it. That's an escape mechanism? Sorry, but giving a few units of currency to my local friendly domain registrar is much, much easier... I think Jos was pointing out just one of many places where there exists a convention of mapping vendor subsets of a "registry" name space onto domain registrations. Yes, Java classes are a more significant example. > The problem is still one of back references for modules that > attempt to add functionality to existing software at runtime, > rather than at compile time, and compile time presence > notification without explicit modification of the packages > being notified (e.g. autoconf "finding" packages on the > developers machine at compile time that are not explicitly > listed as dependencies for run-time). I'm very familar with the necessary structure of dependency graphs in component software, but give me till after my sleep period to figure out if that's relevant to any of the points I was trying to make... But please don't bring such design disasters as autoconf in to muddle the picture... (Hmm, it may not be autoconf's design at fault, but how it's used in every configure script. Without having used it in earnest, I'm given the impression it might be possible to use only autoconf rules which don't "guess".) > The Perl and Java people resolve this by having packages > register themselves into the hierarchy. Admittedly, they > have an advantage, in that they have a module registration > standard mechinism for "class factories" for specific > implementation clases for abstract base classes... but that > was kind of the point. 8-). You don't *have* to be an > interpreter to do this, but it's very easy if you are. Giving preferential power to scripts over worrying about the API was always a Unix strong point. ;-) > In a shell script, the same thing can be accomplished with "ls" > and a "test -x" (ugly, but workable). Ugly? After you just mentioned Perl and Java? I must have misread how long you've been with us, Terry. ;-) Cheers, Mark. -- Mark Valentine, Thuvia Labs <mark@thuvia.co.uk> <http://www.thuvia.co.uk>; "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- <http://www.calvinandhobbes.com>; <http://www.freebsd.org>; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207130414.g6D4EXo6029385>