Re: slashpackage

[prj@xxxxxxxxxxx (Paul Jarc)]

Mike Porter <mupi@xxxxxxxxx> wrote:
> FWIW, it looks to me like this is linux's answer to the BSD ports system.

Not really.  slashpackage was designed made for all flavors of Unix,
not just GNU/Linux; Dan Bernstein, who invented it, uses FreeBSD
lately.  And if it's an answer to anything, it's the tendency of all
Unix distributors to put files somewhere other than where they would
be if you did a default installation from source.  Reliable, fixed
paths is a primary goal.

Now, it happens that slashpackage also introduces a filesystem layout
for packages that makes package management nearly trivial, and I
applied that layout to existing packages in my SPF project.  SPF is
also not entirely Linux-specific; e.g., I've used it for my OpenSSH
installations on Solaris for a good long while.  SPF can also be used
to install Linux itself, and not other kernels, but that's just a
consequence of the fact that Linux is the only kernel (AFAIK)
distributed as a tarball to be installed much like any other package,
so the installation prefix is configurable, etc.  If the BSD kernels
and core tools were distributed that way, I might try to include them
in SPF too.

Note that SPF does not *completely* slashpackagize existing packages.
(For example, the sources are not put in the package's directory under
/package, the package/* metadata files and scripts are not provided,
etc.)  It is, as it's intended to be, a halfway effort.  The job of
complete slashpackagizing must fall to all package maintainers
individually - the gcc maintainers, the Ogg maintainers, etc.  SPF
gives users a taste of what is possible, so that the users can put
pressure on the package maintainers to finish the job.

If the Dragonfly project decides to adopt slashpackage, then that
would mean that your own code would be distributed as tarballs that
unpack under /package into their registered subdirectories.  (Or, if a
CVS-style service is involved, you'd still have registered package
directory names, but the files would get into those directories via
CVS instead of unpacking a tarball.  Not an important difference.)
The sources go in the assigned directory for the package, typically
/package/admin/foo-1.2.3/src/, and then you build it in
/package/admin/foo-1.2.3/compile/, copy the end-result files to other
subdirectories of /package/admin/foo-1.2.3/, and we define that as
installed.  Well, almost - there would also be a symlink
/package/admin/foo -> foo-1.2.3 to specify the current version, and
there would be symlinks for the package's commands in /command and
/usr/local/bin, but no symlinks are needed for headers, libraries,
etc.  Those are all referred to by their exact package-specific
location, not by paths like /usr/include/* or {,/usr{,/local}}/lib/*.
Other software should not look for your files in the traditional
places, because you, as the official maintainer, have said that the
/package/... path is the official place to find those files.  Yes,
this does introduce an incompatibility when you're converting old
packages as opposed to creating new packages, but if you like, you
could create symlinks in the traditional places to soften the blow.
New software that depends on your package, though, should still look
in /package/...; I might install one of your packages on my GNU/Linux
machine, where I do not have symlinks to your files under /usr/...,
and so if I install a dependent package it will fail if it looks
there.

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.

When it comes to repackaging others' code this way, there is the
question of whether such files should have symlinks in the traditional
places like /usr/....  I do not create such symlinks on my machines;
this means that when I install a new package, I *must* do it by adding
it to the SPF system; e.g., /usr/include/zlib.h doesn't exist, so
anything depending on zlib has to be installed under the control of
SPF to ensure that it will look for zlib in the right place.  (I go
even further on my machines; /usr/include, /lib, and /usr/lib do not
exist at all.)  But of course, you could create those symlinks if you
prefer.

> 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?

> 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.)  I have OpenSSH installed in
/package/misc/spf/openssh-3.7.1p2, and OpenSSL installed in
/package/misc/spf/openssl-0.9.7c/lib.  The path to the OpenSSL
libraries is compiled into the OpenSSH binaries via "-Wl,-R," linker
flags.  But the path that is compiled in is not
/package/misc/spf/openssl-0.9.7c/lib; it is
/package/misc/spf/openssh-3.7.1p2/spf/openssl/lib.  Each package gets
a .../spf subdirectory containing symlinks to the packages it links
to.  If OpenSSH and OpenLDAP need different versions of OpenSSL, then
their individual .../spf/openssl symlinks can be set to make them both
happy.  In the normal situation, the /package/misc/spf/openssl symlink
points to the latest version installed on the system, and any
dependent packages that are compatible with that version have their
. ./spf/openssl symlinks pointing to the /package/misc/spf/openssl
symlink.  If OpenSSL is upgraded, those packages will automatically
use the new version.  But if it turns out that OpenLDAP can't use the
latest OpenSSL, then we can set
/package/misc/spf/openldap-2.1.22/spf/openssl to point to a specific
version that will work.


paul