Recording multiple package installs...

Matthew Seaman m.seaman at infracaninophile.co.uk
Wed Sep 8 03:58:38 PDT 2004


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.
> 
> When is the right time to begin that discussion?  :)

Usually when someone pipes up and says "wouldn't it be a good idea if
..." 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=yes' 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.
 
> It still comes down to the fact that the ports tree is being used for
> something for which it was not originally intended. 

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.
 
	Cheers,

	Matthew

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20040908/97aea7c4/attachment.bin


More information about the freebsd-ports mailing list