RFD: A modest proposal #1: /opt
Charles Wilson
cygwin@cwilson.fastmail.fm
Fri Apr 18 23:35:00 GMT 2003
In certain ***RARE*** cases, I believe that a /opt/<package>/ heirarchy
-- with the associated /etc/opt/ and /var/opt/ areas -- is a useful and
necessary expansion of the official cygwin packaging standard. This
would be an acceptable location for *official* cygwin mirror-distributed
packages, but only in rare cases and after per-package justification on
this list. For more information on the /opt heirarchy, see
http://www.pathname.com/fhs/2.2/fhs-3.12.html
Basically, a package to be installed under /opt creates an entire tree:
/opt/<package>/bin
/opt/<package>/lib
/opt/<package>/share
/opt/<package>/man
/opt/<package>/info
/opt/<package>/etc (*)
/opt/<package>/var (**)
(*) contents may be targets of symlinks originating in /etc/opt/
(**) may be a symlink to /var/opt/<package>/
The package will look for its config files (if any) in
/opt/<package>/etc/ (e.g. --sysconfdir=/opt/<package>/etc/), the symlinks
from /etc/opt are placed there to assist the sysadmin.
There's also an optional /opt/bin, /opt/man, /opt/... set of directories
that can OPTIONALLY contain symlinks back to
/opt/<package>/bin/myprog.exe, to prevent PATH / MANPATH / INFOPATH
explosion. BUT, packages installed into /opt/<package>/ MUST work
properly even without /opt/bin & friends.
Rationale:
Mainly, file and executable conflicts. Sure, there are many ways to work
around the problem where <packageA> contains foo.exe, as well as
<packageB>. Some of methods include:
1) Don't Do That. If cvs.exe is part of the cvs package, but cvsnt
also provides a cvs.exe -- then don't allow a cvsnt package into
cygwin. This has obvious downsides...
2) (simple) rename: cvsnt should be hacked to provide cvsnt.exe NOT
cvs.exe. The user is responsible for changing her habits: call
cvsnt.exe when she wants to use that. Or set up shell aliases. etc.
This is quite prone to error -- forgetfulness, aliases don't always
work if part of pipelines, etc.
3) (coordinated) rename: cvsnt should provide cvsnt.exe. cvs should
provide cvshome.exe. Both packages should provide postinstall scripts
that set up a symlink: cvs -> [cvsnt.exe | cvshome.exe]. This is what
my various libpng packages do. Downside: whichever one is installed
(or upgraded) last "takes over" the symlink; the user may not be aware
of this. It also requires that the maintainer of the "original"
package work with the maintainer of the "new" (competing?) package.
Not always a recipe for harmony on the mailing list.
4) "conflicts:" capability in setup.exe: This is a variation on the
"Don't Do That" theme. Downside: doesn't let folks "try out" the
new(er) package. Also, not always possible. For instance, kerberos
provides versions of telnet, ftp, ftpd, etc. However, you can't install
kerberos INSTEAD of inetutils -- because kerberos itself REQUIRES
inetutils.
But, why should we reinvent the wheel? There is an established unix
protocol for dealing with this issue: the /opt heirarchy. inetutils goes
in /usr/ as always -- and kerberos goes into /opt/kerberos/. If a user
wishes to use the kerb versions, he simply adds /opt/kerberos/bin to the
front of his PATH (and /opt/kerberos/lib to LD_LIBRARY_PATH on unix, but
that isn't an issue for us).
(A note on #2 and #3 above): I've found that this is very difficult to do
in practice. It requires huge mucking with the Makefiles and/or ugly
post-install processing of the installed files during packaging. It's a
mess.
Now, if adopted, I believe that the /opt tree should be RARELY used. I
hope we don't see an explosion of official cygwin packages that use it;
MOST packages should continue to go into /usr (or /usr/X11R6/) as before.
Right now, the only candidates for /opt that I can think of are:
kerberos, cvsnt, and the "gnu tool replacements" that ship with ast-ksh.
Oh, and one other thing: the /opt tree should not (according the the FHS)
be solely reserved for distributor use (e.g. official cygwin packages).
Since every package is well-separated into it's own /opt/<package>/ tree,
Bob can provide "Bob's ToolSet" in /opt/bobtool/ if he wants to --
without censure from this list, even if bobtool is not an official cygwin
package.
Comments?
--Chuck
--
Charles Wilson
cwilson@fastmail.fm
More information about the Cygwin-apps
mailing list