Re: slashpackage

[Mike Porter <mupi@xxxxxxxxx>]

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

On Thursday 09 October 2003 01:07 pm, Paul Jarc wrote:
>> Mike Porter <mupi@xxxxxxxxx> wrote:

<snip>
> But as an OS distributor, you're providing more than just your own
> code - you're also repackaging others' code.  That's where SPF, or
> something like it, could be useful.  In that case, the sources could
> go wherever you like, and the installed files go under a directory
> like /package/misc/spf/gcc-3.3.1/ (if you use SPF itself) or
> /package/host/dragonfly.org/ports/gcc-3.3.1/ (if you make your own
> similar system).  You don't have to go for complete slashpackagizing -
> I didn't.  I'd even say you *shouldn't*, for code that isn't yours.
>

BSD already has a similar system (the Ports tree (/usr/ports).  The biggest 
necessary change would be to configure the port-install routines  to 
'install' the files under the ports tree, with appropriate symlinks. (this 
might not work for ports that override the default install, but as has been 
pointed out before, an 85% solution is better than a 0% one...)


> > 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.
>
> Can you explain what you see as the difference between "transparent"
> and "manual"?  E.g., I wrote a script, sp-version, that lets me say
> "sp-version /package/admin/foo-1.2.3", and it will atomically update
> the /package/admin/foo symlink to point to foo-1.2.3.  Is that
> "transparent" enough, or did you have something else in mind?
>

We are talking about having not just 'regular' symlinks, where you could use a 
script like your 'sp-version' to change the symlinks, but 'variant' symlinks, 
which can point different places depending on your environment.  So a user 
might type 'gcc --version' and get 3.4, but when you are building the kernel 
(or world), the system uses gcc-2.95.4 (or whatever version the kernel 
requires)  This happens without the user needing to do anything, and in fact, 
I could be compiling a program with gcc-3.4 in one vty, while I have a 
buildworld going on with gcc-2.95 in another vty, and *there would be no 
conflict*; each build process would simply call 'cc' as it has been on *NIX 
since the beginning of time, and get the 'right' cc version.  More 
intriguingly, it would allow the kernel to be built using 2.95.4, and the 
rest of world (it it supports it) to be built using 3.4 (or whatever the 
latest version is).  Also, once defined, and set in a .profile, I would be 
able to continue to use the same version of gcc, until I decide I want to use 
a different one--without affecting any other user's choice of compiler (or 
other package, as applicable).  Applying this logic to a packing system, you 
could define in the package Makefile which version of (say) gcc you want, and 
the package will be built using that version.  This is more applicable under 
the ports system than /package, as defined, becuase the ports system already 
uses an 'extra' makefile to control the build/installation process, including 
dependencies and so on. (more similar, I think, to your spf, than to 
/package).

> > 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.
>
> SPF has a mechanism to handle that, and this mechanism can be used by
> native slashpackage packages too.  (It just happens that so far, most
> of the people who have adopted slashpackage tend to prefer static
> linking, so it hasn't really come up.) 

<snip>

I realized that, after I made my post.  

The ports system, BTW, already is at least part of the way there, it is 
capable of dealing with a different version of gcc, if a port requires it, 
and is already capable of specifying locations for libraries, allowing us to 
use a similar mechanism of a local directory specifying the links to the 
shared libs.  The only thing missing is a default installation directory 
within the /usr/ports tree, and a mechanism for creating symlinks to 'legacy' 
locations, just in case. (in other words, changing the install behavior from 
moving the file to /usr/local/bin, to creating a symlink in /usr/local/bin)

Such a change would be relatively easy to acomplish, and would allow us to 
continue to use the vast majority of existing ports in the bsd ports 
collection, while easily adding additional features for 'new' ports (in other 
words, we retain backwards compatibility with the 5000+ existing ports, and 
add new functionality for those who wish to write dfports.)

Well, time to go earn a paycheck and stop bothering the rest of you...

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

iD8DBQE/hc3hY30jZzkECLcRAkWPAJ9IOtvw0c4v+gwZNUmvbaRyzNFn/wCfd5Vs
3u44mmBzDHRtWGtHrJw693U=
=0ZE9
-----END PGP SIGNATURE-----