Date: Sat, 13 Jul 2002 00:24:26 +0100 (BST) From: Mark Valentine <mark@thuvia.demon.co.uk> To: Terry Lambert <tlambert2@mindspring.com> Cc: Wes Peters <wes@softweyr.com>, Jordan K Hubbard <jkh@queasyweasel.com>, Dan Nelson <dnelson@allantgroup.com>, Archie Cobbs <archie@dellroad.org>, Dan Moschuk <dan@freebsd.org>, Dag-Erling Smorgrav <des@ofug.org>, arch@freebsd.org Subject: Re: Package system flaws? Message-ID: <200207122324.g6CNOQ7L020672@dotar.thuvia.org> In-Reply-To: Terry Lambert's message of Jul 12, 3:19pm
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? > At this point, the best approach is probably a registry. It already exists for our purposes: /var/db/pkg. One improvement to its existing structure would be to move all the FreeBSD package metadata under a freebsd.org sub-directory, and have all FreeBSD ports register under this vendor name space, allowing other vendors' packages to co-exist more easily using the same base system tools. (Using a seperate pkg db area would acceptable, but only if the location could be specified within the package metadata; i.e. pkg_add /cdrom/mypkg.tgz should work for third party packages without having to specify additional options.) I'm speaking as a vendor who intends to ship binary packages (albeit supplied with full source; it's just easier for customers who don't [yet] need to customise); some will be proprietary, others will be versions of software for which FreeBSD already has ports; currently I just intend to prepend an almost unique prefix to the package name (and of course install it somewhere unlikely to clash with another vendor's packages). Being guaranteed the /var/db/pkg/thuvia.co.uk/* (or /var/db/pkg/uk/co/thuvia/*, whatever) name space would be better, of course, as would be being able to re-target the installation (but I can of course resort to my icky hack of editing the binaries in a post-install script if this becomes an issue). > While it's theoretically possible to edit this data in place, > assuming the path is not assembled from components at runtime, > in practice, you are limited to a path of equal or smaller size. My location strings would be padded out to a reasonable maximum size. > A lesser alternative is to have a "/var/opt" or some other > location which is guaranteed to be a symlink to the real path > location... and is never, itself, a real directory. Well, we could already create such a symlink, even on a per-package basis, as (for example) /var/db/pkg/foo-x.y/location... > In an ideal world, you would probably want to put each package > and all dependent files, including the shared libraries it > cares about, into its own directory. This was really Windows > original problem. I'd rather put some trust in our shared library versioning and package dependency schemes, and actually share the shared libraries where it makes sense... However, you're already free to use your own policy here. > A number of researchers have suggested that this problem could > be solved by causing packages themselves to be in directories > that were exported as their own mini FS's. This "live image" > could be mounted read-only off a remote server, or locally off > a CDROM, without introducing further issues. See QNX 6 for an implementation which actually looks like it might be functional! (These QNX folks are smart.) The package installs in its own private area, and registers with the package file system so that its component files magically appear in all the expected places in /usr/bin and so on. > There are really three problems with this: > > 1) Windows is limited to 26(32) mount points: one per drive > letter; Not that I care a whit about whether our packaging scheme would work with Windoze, but I vaguely recall hearing news of them fixing that a few years back... > I personally don't know if I'm ready to fight the "Not Invented Here" > war that trying to implement a registry entails. There are plenty of lightweight UNIX-like mechanisms to solve all the problems they tried to solve with that mess. And you don't have to solve them all using the same one... 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?200207122324.g6CNOQ7L020672>