Date: Wed, 8 Sep 2004 11:56:14 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Paul Chvostek <paul+fbsd@it.ca> Cc: ports@freebsd.org Subject: Re: Recording multiple package installs... Message-ID: <20040908105614.GA11639@happy-idiot-talk.infracaninophile.co.uk> In-Reply-To: <20040908050632.GA15695@it.ca> References: <20040907175516.GA79688@it.ca> <20040907185444.GA2487@happy-idiot-talk.infracaninophile.co.uk> <20040908050632.GA15695@it.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
--9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Sep 08, 2004 at 01:06:32AM -0400, Paul Chvostek wrote:
> On Tue, Sep 07, 2004 at 07:54:44PM +0100, Matthew Seaman wrote:
> > 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.
>=20
> When is the right time to begin that discussion? :)
Usually when someone pipes up and says "wouldn't it be a good idea if
=2E.." on a mailing list or the like.
I do quite like this idea, but personally I can't quite see how to
implement it cleanly and unobtrusively given the way ports works at
current.
> 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.
Ideally the Makefile, etc. machinery for having a port support
installing multiple instances of itself should be developed as
generically as possible, but that machinery should be disabled by
default, and only enabled if the port maintainer puts (say)
'ALLOW_MULTIPLE_INSTANCES=3Dyes' into the port Makefile. A similar
capability would probably have to be added to the pkg handling tools:
eg. add a flag to pkg_add(1) '-i instance' to install a pkg using that
instance. And all of that would have to be done in a fashion to
maximise backwards compatibility.
You'ld need to keep track of all the different settings for each
instance, which suggests that adding a new standard 'PKGINSTANCE'
variable to the system would be a good idea. If that's undefined,
everything works exactly as it does now. If it is defined, then
you'ld want to do things like modify the OPTIONS processing to keep
the port settings in /var/db/ports/${PKGINSTANCE}/${LATEST_LINK}, and
similarly the package data would go into
/var/db/pkg/${PKGINSTANCE}/${PKGNAME} -- or some variation along those
lines)
It would be good to have handy features like -- you can install
multiple instances from the same build of a port without having to
rebuild each time (unless you wanted a different set of OPTIONS for
each instance, of course). Similarly it would be good if you could
take a regular package from one of the FTP servers and install
multiple instances of it to different locations. Anti-foot shooting
mechanisms -- eg. a port should automatically conflict with another
instance of itself (including different version numbered ones), unless
it was being installed to a location distinct from any other used by
its various incarnations.
Thinking about it, being able to have several different versions of
the same package installed at once would be a very useful feature.
But that means you'ld have to do some scrabbling around under
/var/db/pkg to identify all of the different versions and instances
and check that nothing conflicted if you wanted to reliably miss
when shooting at your feet.
=20
> It still comes down to the fact that the ports tree is being used for
> something for which it was not originally intended.=20
Heh. Being able to use software in a way never imagined by its
authors is generally held to be the mark of great software.
> 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....
Cool. Patches speak louder than words though.
=20
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
--9amGYk9869ThD9tj
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)
iD8DBQFBPuVOiD657aJF7eIRAj2fAJ4xzWdSd8yfbWetF4cOBLE5CrgczgCcDsFD
gLStJhWLKJKX6gaAsNJdJ9c=
=7x3p
-----END PGP SIGNATURE-----
--9amGYk9869ThD9tj--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040908105614.GA11639>