Date: Fri, 12 Jul 2002 15:19:46 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Mark Valentine <mark@thuvia.demon.co.uk> 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: <3D2F5602.9039F5DE@mindspring.com> References: <200207120055.g6C0tbpQ084565@dotar.thuvia.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Valentine wrote: > wes@softweyr.com (Wes Peters) > > On problem in particular comes from changing the PREFIX of a > > package. You can easily do this in the package tools, but how do you > > change the BINARIES to realize they've been installed under another > > PREFIX? > > How about providing a packaging API call (and utility) for the packages > to grab their install root from a record in /var/db/pkg? Something > like pkg_getroot(3) and pkg_config(1). > > There probably isn't much less intrusive way to make a package's root > configurable at install time. > > If you didn't want the package to have to look in /var/db/pkg, have > the package binaries hold a maximum-length padded string variable (marked > similarly to what(1) strings), and provide a tool to edit the binary (and > scripts) at install time. > > I think environment variables are too fragile for this purpose. At this point, the best approach is probably a registry. The problem that you are trying to solve with this is that there is implied knowledge of a fixed path which is compiled into data stored in the binary. 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. 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. This still would not address the ability to locate packages in more than one installation target location at a time, when you have multiple packages on a system: you are still limited to one directory hierarchy. 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. 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. Likewise, it would permit control of licensing by providing a usecount control point that could be monitored asn adminstered centrally, with little additional effort. The main benefits to this are that you install an application once, it never interferes with the operation of another applicaiton, and it's location is a Schelling point which can be identified by other applications easily, if they depend on it. A secondary benefit is that, "if you need powerpoint for a presentation, you can mount it from the local public network and use a local license instance, rather than carrying it around with you". That's probably not a "benefit", if your job is selling as many "powerpoint" licenses as humanly possible. 8-). There are really three problems with this: 1) Windows is limited to 26(32) mount points: one per drive letter; so it is difficult to make this work in Windows, though it can be done... either through unification of the applicaiton namespace on a local network through peer-to-peer implementation, or through a single FS that hooks IFSMgr to turn directories themselves into mount points in the Windows FS namespace, rather than relying on the Windows "drive letter" mechanism, whose only benefit is "it's already supported". 2) Applications vendors don't write applications this way, so needing them to be written this way implies a constraint on porting. 3) Cross-references are unidirectional along a graph edge; the implications of this may not be obvious at first, but to break it down into simple terms: it's hard to add plug-ins to applications that already exist, without those applications knowing about the possibility of a given plug-in at the time they are written, without writing the plug-in to a directory owned by the original application -- thereby violating the model; e.g.: C:\Program Files\Netscape\Communicator\Program\Plugins Once again, some of this can be resolved... with a Schelling point that is location invariant ... or within which, locations are themselves invariant: once again... a registry. I personally don't know if I'm ready to fight the "Not Invented Here" war that trying to implement a registry entails. As an idea that came from Windows, there is a gut-level reaction among many UNIX people that tries to pretend that engineers employed by Microsoft (or, sometimes, even RedHat) could not possibly have a good idea on their own, or solve a problem in a way that was not already thought of by themselves. Maybe we can table the "change PREFIX on binary during install" issue while we slog through the rest of the mess, and then come back to it when people aren't looking? 8-). -- Terry 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?3D2F5602.9039F5DE>