Date: Fri, 3 Nov 2000 00:44:01 +0200 From: Neil Blakey-Milner <nbm@mithrandr.moria.org> To: Tim Kientzle <kientzle@acm.org> Cc: Jordan Hubbard <jkh@winston.osd.bsdi.com>, Patrick Bihan-Faou <patrick@mindstep.com>, "Daniel C. Sobral" <dcs@newsguy.com>, libh@FreeBSD.ORG Subject: Re: Making the Packages System Better Message-ID: <20001103004401.A60432@mithrandr.moria.org> In-Reply-To: <3A0065EC.C4ABA4AD@acm.org>; from kientzle@acm.org on Wed, Nov 01, 2000 at 10:50:20AM -0800 References: <21943.973069819@winston.osd.bsdi.com> <3A0065EC.C4ABA4AD@acm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001103004401.A60432>