Re: [SLUG] Derek's partitioning rant

From: Ian C. Blenke (icblenke@nks.net)
Date: Sat Sep 21 2002 - 17:57:20 EDT


On Fri, 2002-09-20 at 10:57, Derek Glidden wrote:
> Is it really? I've never actually looked at the FHS or the LSB or
> anything like that. Does it use the same arguments in favor of /opt?
> I've just been "an /opt kind of guy" for pretty much ever. What can I
> say, I'm ahead of the curve. :)

I'm kind of the /opt "hater". Yeah, I'll use it if it's "the standard"
way of building packages in a particular enterprise environment, but
don't make me like it.

I like seperating my code from the config and persistent data that makes
it run, ala:

Using pkglink, I follow what James Neal and I worked out to be the
"pkgs" packaging system at 2c2:

Locally (node local) or Remote (NFS or otherwise) package:

        /local/pkgs/openssh
        /remote/pkgs/Linux/Debian-3.0/ia32/data/openssh
        /pkgs/openssh (symlink soup of /local and /remote pkgs)

and the package config data:

        /local/data/openssh
        /remote/dist/Linux/Debian-3.0/ia32/data/openssh
        /data/openssh (symlink soup of /local and /remote data)

The source is kept with the package:

        /pkgs/openssh/src (source tree)
        /pkgs/openssh/src/openssh-3.4p1

Then, when built, it is installed with a --prefix of the version in
/pkgs/{packagename}/{version}:

        /pkgs/openssh/3.4p1
        /pkgs/openssh/3.4p1/lib
        /pkgs/openssh/3.4p1/bin
        /pkgs/openssh/3.4p1/...

The "current" version is a symlink to the version that should be
considered the latest version.

        /pkgs/openssh/current (current -> 3.4p1)

The "u-tree" version is a symlink to current (usually) that is used when
building the symlink soup false /u tree:

        /pkgs/openssh/u-tree (u-tree -> current)
        /u (symlink soup of all /pkgs/*/u-tree dirs)

This leads to a simple user environment for pathing:

        /u/bin/ssh

Now, the global config data is kept in /remote or a /local cache:

        /remote/dist/`autoarch -a`/data/openssh
        /local/dist/`autoarch -a`/data/openssh

and any node-local config data, or data with persistent node-local junk,
is kept in /local/data:

        /local/data/openssh

This is all merged into a /data symlink soup:

        /data/openssh (link -> /local/data/openssh)
        /data/openssh/sshd_config

All packages are built against the /pkgs/{packagename}/{version} paths,
so that older packages can rely on older libraries while newer libraries
are being used with newer packages. When building, /u/lib is not used in
favor of the full /pkgs/openssl/0.9.6g/lib - keeping version
independence.

There's nothing wrong with supporting locally built packaging systems on
a per-platform basis. Solaris pkg's exist for opensource tools from
sunfreeware (and pkg-get isn't half bad), Debian debs are wonderful in
concert with apt-get, and RedHat/SuSE/Mandrake RPMS are fine with
apt4rpm, but merge a network together with ALL OF THESE, and *YOU* try
keeping them up to date and supported. It's a nightmare at best.

When I look at an /opt tree, I typically see a mess. The above may first
appear to be a mess, but when you're supporting a number of
architectures on a number of platforms, and trying to keep an enterprise
working and up to date, it's simply the best way to get the job done.

"Symlink soups" can be a lifesaver (if not a general waste of inodes ;)

I guess what I'm really trying to say here is that there are other
correct ways of laying out Unix filesystems *WITHOUT* /usr, /usr/local,
or /opt. In fact, you can get by quite well without /var as well - as
I've done with a /data soup. Yeah, it's not LFS or FHB, but who cares?

I'd love to make a Linux distribution based entirely on the above
schema. Right before 2c2 folded, James and I had been talking about a
dependency metadata tree for working out true independant packages. It
would be a merge of gentoo like ideals with a Unix purity of thought: no
proprietary packaging, just tarballs and a few base scripts to build and
maintain it.

That's my take on packaging. Think Different.

- Ian C. Blenke <icblenke@nks.net> <ian@blenke.com>



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 19:56:34 EDT