From owner-freebsd-libh Thu Nov 2 14:44:11 2000 Delivered-To: freebsd-libh@freebsd.org Received: from rucus.ru.ac.za (rucus.ru.ac.za [146.231.29.2]) by hub.freebsd.org (Postfix) with SMTP id C412137B4CF for ; Thu, 2 Nov 2000 14:44:04 -0800 (PST) Received: (qmail 70997 invoked by uid 1003); 2 Nov 2000 22:44:01 -0000 Date: Fri, 3 Nov 2000 00:44:01 +0200 From: Neil Blakey-Milner To: Tim Kientzle Cc: Jordan Hubbard , Patrick Bihan-Faou , "Daniel C. Sobral" , libh@FreeBSD.ORG Subject: Re: Making the Packages System Better Message-ID: <20001103004401.A60432@mithrandr.moria.org> References: <21943.973069819@winston.osd.bsdi.com> <3A0065EC.C4ABA4AD@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A0065EC.C4ABA4AD@acm.org>; from kientzle@acm.org on Wed, Nov 01, 2000 at 10:50:20AM -0800 X-Operating-System: FreeBSD 4.1-STABLE i386 X-URL: http://mithrandr.moria.org/nbm/ Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed 2000-11-01 (10:50), Tim Kientzle wrote: > > > the approach that has been described is sound. However I would also like to > > > hear about the arguments of people who oppose this. Maybe there is something > > > that we missed and that will byte us badly at some point ? > > > > There are a number of more complex packages which "find" themselves by > > examining argv[0] (or $0 if, more typically, they're scripts which > > front-end executables which require significant environmental > > pollution to run). These packages are often confused by finding their > > base to be a symlink and will do parent-directory (..) relative path > > smashing to find their other bits. If this fails to work, you're > > hosed. > > > > These "complex packages" are also not very rare - both emacs 20.x as > > well as java come immediately to mind, and there are others. > > > > - Jordan > > Later JDK releases are symlink-aware and do not have this problem. > (I know for a fact that the native JDK 1.2.2 is symlink-aware. > The Blackdown Linux JDK 1.2.2 is also symlink-aware, so I think > it's a fix that's been incorporated in Sun's sources, not just > a FreeBSD-specific fix.) > > There's also a stock workaround that should work for any such program: > > $ cd /usr/packages/emacs-20.35 > $ mkdir bin-private > $ mv bin/emacs bin-private/emacs > $ cd bin > $ cat >emacs > #!/bin/sh > exec /usr/packages/emacs-20.35/bin-private/emacs "$@" > ^D > $ chmod +x emacs > > Now, a symlink from /usr/packages/bin/emacs to > /usr/packages/emacs-20.35/bin/emacs will invoke this > shell script which will exec the "real" emacs with > all of the expected path information. If anyone cares, I actually like Tim's suggestion in theory, and think it's worth having some parallel testing going once someone has got it implemented. I'm talking maybe dedicating a few cycles to building these packages and having people try it out a bit in testing, maybe mixing it up with ports built with STOWLIKE_PREFIX set. I wrote a reasonable amount of stuff necessary for this about this time last year, but I don't seem to have it anywhere. I think the joke was 'FIRE - FreeBSD Install Relocation Engine' to which was extended "Fireman" and many other amusing sidetracks. It might be with the rest of the portconf stuff I was playing with on at the time (and thus got left behind when I moved on and couldn't get any comments) on one of my machines that currently isn't up, though. The only disadvantages are really human-relations stuff, which I'm pretty sure won't be as bad as some worry. I remember battling with whether to have a consolidated "etc" directory which were actually files, not symlinks - it's more consistent with most other systems. We could symlink "foo.conf-dist" as usual, though. This means local configuration stuff is always there, and may even improve the shared-vs-local filesystem situation. I'm not religious on this one, but I think it makes sense (with the obvious "add a default config if there isn't one, delete the config when you uninstall/upgrade and the config is unchanged" rules being taken care of by the package tools). Since there's going to be a massive shift with the new system, I think it could slip in reasonably with the rest of the stuff, especially if we decide to go for /usr/packages. New package format, new package database, new installation and package tools are more likely to be the hot items. Neil -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message