Date: Wed, 8 Sep 2004 01:06:32 -0400 From: Paul Chvostek <paul+fbsd@it.ca> To: ports@freebsd.org Subject: Re: Recording multiple package installs... Message-ID: <20040908050632.GA15695@it.ca> In-Reply-To: <20040907185444.GA2487@happy-idiot-talk.infracaninophile.co.uk> References: <20040907175516.GA79688@it.ca> <20040907185444.GA2487@happy-idiot-talk.infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <paul@it.ca>
Operations / Abuse / Whatever
it.canada, hosting and development http://www.it.ca/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040908050632.GA15695>