This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: RFD: A modest proposal #1: /opt
- From: "Charles Wilson" <cygwin at cwilson dot fastmail dot fm>
- To: cygwin-apps at cygwin dot com
- Date: Wed, 21 May 2003 23:41:38 -0400
- Subject: Re: RFD: A modest proposal #1: /opt
- References: <20030418233522.8955D51A8B@smtp.us2.messagingengine.com>
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