From owner-freebsd-ports@FreeBSD.ORG Wed Sep 8 05:06:34 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA41516A4CE for ; Wed, 8 Sep 2004 05:06:34 +0000 (GMT) Received: from haggis.it.ca (haggis.it.ca [216.126.86.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6644143D54 for ; Wed, 8 Sep 2004 05:06:34 +0000 (GMT) (envelope-from paul@haggis.it.ca) Received: from haggis.it.ca (paul@localhost [127.0.0.1]) by haggis.it.ca (8.12.11/8.12.11) with ESMTP id i8856Xld049510; Wed, 8 Sep 2004 01:06:33 -0400 (EDT) (envelope-from paul@haggis.it.ca) Received: (from paul@localhost) by haggis.it.ca (8.12.11/8.12.6/Submit) id i8856Xoh049509; Wed, 8 Sep 2004 01:06:33 -0400 (EDT) (envelope-from paul) Date: Wed, 8 Sep 2004 01:06:32 -0400 From: Paul Chvostek To: ports@freebsd.org Message-ID: <20040908050632.GA15695@it.ca> References: <20040907175516.GA79688@it.ca> <20040907185444.GA2487@happy-idiot-talk.infracaninophile.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040907185444.GA2487@happy-idiot-talk.infracaninophile.co.uk> User-Agent: Mutt/1.4.2.1i Subject: Re: Recording multiple package installs... X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2004 05:06:34 -0000 On Tue, Sep 07, 2004 at 07:54:44PM +0100, Matthew Seaman wrote: > > > It would seem that ports like www/gallery (and databases/phpmyadmin and > > others) could do with some way to idenfify the different installs that > > might occur on the same host. So ... where to record that? > > I don't think anyone has yet considered modifying the ports system to > handle multiple installations of the same package -- possibly because > the original thought was that ports would install binaries into a set > of directories that everyone could share. Adding the machinery to be > able to cope with multiple instances of web content or other ports > that could conceivably act the same way is going to require some > serious re-working of the ports infrastructure. When is the right time to begin that discussion? :) Just because I'm a neophyte ... what needs to be reworked? The infrastructure seems to support recording dependencies just fine. We already have ports which are "versions" of other ports using MASTERDIR. All that seems to be different here is that we're talking about allowing ports to be customized arbitrarily within a set of rules rather than statically, as set in the ports tree. If both "gallery-spoo-0.99.5_2" and "gallery-flarn-0.99.5_2" are installed, both depending on netpbm, it doesn't seem to me to be much different than if I installed two different ports that also require netpbm. netpbm's +REQUIRED_BY lists packages, and dependency upgrades go back to gallery-spoo-0.99.5_2 et al to find out what to do. So ... upgrades. If it's not already possible within the structure of +CONTENTS, we could add another file that would include relevant variables that need to be set in order to build gallery for "spoo". Seems like a SMOP, though I may be talking through my hat. (Details should be worked out only after the direction and concept are clear.) And ... package removal. If a particular port has a different @cwd, that's nothing new. We already have a number of @cwd's in play, sometimes within a single port. The common locations are sanctioned, but they seem to me just to be different PREFIXes. @cwd doesn't care, so package removal may not be affected. Next ... package creation. Sure, but aside from compiled CGI software, I can't think of a multi-install port that would actually *require* use as a package. The goal here is to use the existing ports system to streamling installation and upgrades for locally-customized content. If we can't drag along the package creation process into this new use for the ports tree, I won't lose much sleep over it. So ... what else may be broken? > However, I'm asking myself in what circumstances you'ld want to do > this? Certainly with www/gallery that would perhaps be in order to > support individual local users? We already have lots of ports that are closer to "content" than system-wide, whether that content is associated with a particular user or something else. www/gallery, databases/phpmy*, www/zope*, the various wikis, etc... Most of these are at least as likely to be installed for an Apache virtualhost as they are for the default web server. And I doubt many vhost documentroots live in $PREFIX. :-P For some ports, the thing that would make multiple installs distinct would be the target directory. For other ports, it might be something else. The former case is the only one I've come across thus far. >In which case, you can let each user > have their own private package database. Setting the following > environment variables will enable individual users to install most > packages and ports without needing super-user privileges and without > interfering with other users' locally installed ports/packages: > > setenv WRKDIRPREFIX ${HOME}/ports > setenv PKG_DBDIR ${HOME}/db/pkgs > setenv PORT_DBDIR ${HOME}/db/ports > setenv PREFIX ${HOME} > setenv INSTALL_AS_USER yes > setenv PACKAGES ${HOME}/packages All well and good, but there's no chance that I'm going to manage a private package database for one or two packages. And for users who have trouble telling the difference between FTP and email, giving them the tools to do this stuff themselves won't fly. If private package databases are the "right" way to do this, then I'll skip the ports system for this sort of thing and continue installing from original distributions. That's more work than it's worth. > URLs. A similar trick can be used for installing software > into multiple jail(8)s, although simply logging into each jail and > installing from there is often easier. A jail is much more expensive to run than a virtualhost. More obviously, a thousand jails are more expensive to run than a thousand virtualhosts. It's the right solution for some users, but not for most. It still comes down to the fact that the ports tree is being used for something for which it was not originally intended. There are three choices. We can adjust the ports system to handle the "new" use. Or we can stop using the ports system for software that's out of its scope. Last, we can continue to limp along, providing a half-assed solution by failing to address the issue. I'd prefer door number 1.... > you're going to have to edit pkg-plist to insert absolute paths. > Which is not too bad if you're installing from ports, but any package > created from such a port would end up installing to a compiled-in > fixed location, rather than one relative to $(PREFIX). If the plist can remain relative to a custom PREFIX, this shouldn't be necessary. And if you're setting a custom PREFIX, you probably don't need to generate a package, as I said. Problem definition time. I'm trying to propose changes that would allow for a specific case that *I* am seeing (content-ports which are installed to multiple targets). Can you (or anyone) see related issues with the existing ports system that should be addressed by the same solution? > Other than the whole ports system being designed to enforce hier(7) > and install everything relative to $(PREFIX)? Ya, that's where we're falling down. hier(7) makes no mention of user data. The ports system is NOW BEING USED to install software that is outside the scope of hier(7). We can update the ports system policies to reflect current use, update current use to reflect policies, or just resign ourselves to the SNAFU. What's your poison? -- Paul Chvostek Operations / Abuse / Whatever it.canada, hosting and development http://www.it.ca/