Re: [forward] FHS pre-2.1 draft #3 on web site
On Thu, Sep 23, 1999 at 11:24:37AM +0100, Philip Hands wrote:
> It strikes me that if all the distributions include these directories
> by default, that ISV installer writers will put stuff like:
>
> for i in $PACKAGE_DIR/bin/* ; do ln -s $i /opt/bin ; done
>
> in their install scripts. This is broken, since the whole point of
> having the /opt hierarchy is that they only have to succeed in using a
> unique name for their package, and then they can have any names they
> like within the package without breaking anything. As soon as they
> assume that they get to play with the /opt/{bin,man,...} directories,
> we're back into a name conflict minefield.
Ok, let me take a step back and talk about the larger scene...
At the moment, it looks like commercial vendors are going to build red-hat
specific rpms, then use alien to generate debs. So most of the rules
for commercial vendors will be dictated by Red Hat, and we'll have some
minor influence on the process.
I think that we should plan on having some documentation up on our web
site with recommendations for commercial vendors. I think that our
recommendations should be as simple and straight-forward as possible.
[Perhaps streamlined documentation from all our various manuals with just
the parts of interest to commercial vendors, with quick start information
on debian-rules and lintian.]
Perhaps, once debconf is released, we ought to provide something like
update-opt so that commercial packages can easily let the sysadmin build
appropriate links in /opt/bin, /opt/man, etc.
> Given that we're into reliability, we can help spot these bugs by not
> having the directories. Broken packages will then fail to install,
> which is in the public interest, because those bugs are likely to get
> fixed _before_ they bite someone.
If they're going to build those links and they're going to support
any of the existing FSSTND systems out there their script will have
mkdir -p /opt/bin in it.
Our job is to give them a better alternative.
> The fact that the FHS makes their existence optional, means that it's
> not insisting that we install them.
True, but this doesn't solve any problems as far as I can see.
> If you think that documenting the symlink installation that the
> sysadmin is expected to do is sufficient (I do), then surely asking
> them to first do a mkdir is not actually going to tax their abilities.
I don't think it's going to tax the abilities of an experienced sysadmin.
I think it adds an extra step (and unneeded verbage) which would be a
distraction for novice sysadmins.
> > If we don't support this, if we expect users to just know that they can
> > create directories, and just know what config files to edit and how to
> > edit them, then it's going to take a lot more than a single sentence to
> > get them going.
>
> No, I say support our users, tell them about ``mkdir /opt/bin'', just
> don't do it for them.
Why? So far you've offered two reasons: because we have the option of
not doing it [this isn't a real reason]. And to catch hypothetical
bugs in packages which we aren't supporting [even if we do catch bugs
this way, what are we going to do about it? I mean, besides putting
in our FAQ: you have to mkdir /opt/bin/].
> I cannot see how leaving out the directories makes the admin's job any
> more complex. The real complexity is in deciding which binaries one
> needs to link, which ones to wrapper, where to put /opt/bin in the
> path, what to do about man page name conflicts, and what the
> implications of upgrading the package are after you've created this
> mess in /opt. Running mkdir a few times is a drop in the ocean.
mkdir /opt/bin ought to happen when the first /opt package is installed.
This complexity you're talking about wouldn't happen till much later:
They're not comparable.
> Also, from a purely subjective & trivial point of view, I know that I
> will never install anything under /opt on any of my systems, so why
> should I have to see an untidy directory tree when I do find's, du's
> etc.
Perhaps this means that /opt support should be in a standard package
rather than part of the base? [Then again, maybe the LSB reference
system will include /opt directories...]
> Since you admit that actual documentation is required anyway, why not
> document their creation too.
Given the choice between writing extra documentation and making a
fairly trivial system change it's usually a good idea to opt for simpler
documentation.
> As far as $PATH goes, where does it go in the path ?
I'd put it at the right end.
> If I install a Debian system solely as a platform on which to run
> oracle (say), then I'd probably put /opt/oracle/bin as the first thing
> in the path, because I don't give a damn about name conflicts, as long
> as oracle works.
You can do that. That doesn't need to be the debian default.
> So, obviously, we need to put the /opt/bin near the end of the path.
> Now what happens when a new version of a Debian package happens to
> have an overlap with an /opt package. Let's say oracle has a
> ``dbhalt'' command that ensures that the database is in a state ready
> for a clean backup. Now a new version of postgresql introduces a
> binary called dbhalt. Six months later you hard disk dies and you
> find that all you oracle bakups are shite, and you're company just
> went out of business.
Does dbhalt prompt for a password, or can anyone who runs it shut down
the database? Is it run from cron (which doesn't use /etc/profile)
or is it run from the command line? When you restart oracle, won't
it complain if oracle is already running? What happens if you run
the dbhalt for the wrong instance of oracle (since oracle offers
lots of opportunities for parallel installations).
> The way to address this sort of problem is to have the backup cron job
> refer to /opt/oracle/bin/dbhalt, in which case /bin/opt is redundant.
Ok, so it is a cron job. Which means that /etc/profile is irrelevant.
--
Raul
Reply to: