This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RFD: A modest proposal #1: /opt


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 at fastmail dot fm


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]