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]

Re: RFD: A modest proposal #1: /opt


This conversation died out without a conclusion last month.  If nobody
else cares very much, but I think this idea is
peachy-with-a-side-of-keen, does that mean I win? <g>

Seriously, may we extend the 'official cygwin file system standard' to
include an FHS-like /opt tree, for RARE use (e.g. only when the
cygwin-apps community, during ITP discussion or package-review phase,
arrives at a consensus that package FOO will be allowed to live in /opt)?

IMO, the only current candidates for "/opt" treatment -- if we choose to
allow it -- are the ast-open toolset, and the kerberos toolset, which
each provide alternate implementations of existing tools in other
packages.  (I think the emerging symlink-based solution w.r.t. to pdksh
and ast-ksh is appropriate; I don't think ast-ksh should be an /opt
package.  But ast-open should be.)

--Chuck


On Fri, 18 Apr 2003 19:35:22 -0400, "Charles Wilson"
<cygwin@cwilson.fastmail.fm> said:
> 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?

--
  Charles Wilson
  cygwin at removespam cwilson dot fastmail dot fm


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