DragonFly kernel List (threaded) for 2003-10
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: slashpackage
-----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-----
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]