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