Re: slashpackage

[Mike Porter <mupi@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 08 October 2003 02:41 pm, Paul Jarc wrote:
> I read the packaging page at
> <URL:http://www.dragonflybsd.org/Goals/packages.cgi>.  It looks like
> you might be interested in the slashpackage system:
> <URL:http://cr.yp.to/slashpackage.html>
> <URL:http://multivac.cwru.edu./spf/>
>
> With slashpackage and SPF, it's possible to have multiple versions of
> a package installed simultaneously, and it's possible for each package
> to use a specific version of each of its dependencies.  This does not
> require any special tagging of binaries, or any kernel changes to make
> files visible or invisible.


FWIW, it looks to me like this is linux's answer to the BSD ports system.

The only functional difference I can discern is that the actual executable 
files reside within the /package directory, something that should be 
relatively easy to implement: instead of actually copying the files to the 
destinations, we create symlinks.  The other major difference, thought it 
doesn't strike me as terribly significant, is that it uses the filesystem 
itself to determine what packages are installed.  This would be possible, but 
would require some changes to the ports tree; I am also not entirely sure it 
is necessary. 

This doesn't, actually, strike me as that bad of an idea.  It might require 
some changes to how cvsup works in the ports tree (you *defintely* wouldn't 
want strict-mode enabled!!) and would require a stricter versioning in ports 
(EVERY port would need to include a version number).  We could then link, to 
pick something I have been fighting with lately, /usr/ports/security/amavisd 
to /usr/ports/security/amavisd-0.1 to get close to the functionality we have. 
(actually, if we are consistent about it, it could greatly increase the 
functionality, IMO).

If we combine this with variant symlinks, so we can transparently switch 
between versions of programs, without having to manually edit symlinks all 
the time, and I think we could be more than 1/2 way there.

Note, however, that this whole slashpackage system still doesn't address one 
of the major things we want to deal with, namely, the ability to have a 
program run with the correct varsions of shared libs, which I suspect is 
going to be the major ports problem we need to face.  I don't think there 
will be an answer to this, without either forcing explicit use of shared libs 
in the application directory (did somebody say, a separate copy of how many 
files for eavry port in gnome???), or doing some sort of 'application 
tagging' as Matt suggests, allowing the program to only see the version of 
libc.so that it wants.needs. (Variant symlinks alone won't really address 
this issue either, although it allows some workarounds. (create a user than 
can't login with a profile that matches the library versions we need, then 
make the binary setuid that user, for example; I know, that opens a whole 
other can of worms)

Even with changing the ports tree so that the installed ports/packages could 
be determined by the tree itself, I think that there is nothing here that 
would 'break' the existing ports, allowing them to work unmodified in the new 
system, while ports written specifically for the new system could take 
advantage of other features.  The reason I say this is that the major changes 
required are pretty much all in files included from the base bsd.ports.mk 
file.  If I had more time, or could justify it for work, I would be willing 
to tackle such a change....

mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE/hJkDY30jZzkECLcRAmy0AKCHE6ViUfyW/7iNPnMdoh5leDqaOACgnJ4J
14ZN0MYQH10eZv0I/R9O5oI=
=hcnN
-----END PGP SIGNATURE-----