Re: [forward] FHS pre-2.1 draft #3 on web site
Raul Miller <moth@debian.org> writes:
> On Wed, Sep 22, 1999 at 04:18:07PM -0700, Chris Waters wrote:
> > Oh c'mon. You're talking about people who are smart enough to create
> > symlinks in /opt/bin, but aren't smart enough to create the dir in the
> > first place? I don't buy it. :-)
>
> The issue isn't that they don't know how to create directories -- the
> issue is that without the directories there as a hint, there's a
> decent chance that it's not going to even occur to them to do. For
> example, there are some debian developers who have paths longer than
> 1k on non-debian systems, yet there was nothing stopping them from
> creating an /opt/bin on those non-debian systems.
The reasons that I rarely did that when I used to have to put up with
path bloat were:
There's no guarantee that the ISV programmer is not doing something
broken and stupid with argv0, which would fail if you changed the path
the directory the program was called from.
name conflicts between ISV packages mean that you have to specify the full
path in scripts and the like anyway, so what's the point of having a
link into one's path.
different users have different priorities, so can solve the name space
pollution problem by pathing to their most used package(s), and
typing full paths (or making aliases) for the secondary packages.
upgrading third party packages is fraught enough as it is (since the
office junior is often given the job of writing the install scripts,
and one regularly sees them sent out not only broken, but with
syntax errors in them). If you add to that the fact that your hand
installed symlinks may end up dangling, because of pointless
upstream changes, you get to the point that you'd rather not upgrade
at all.
> If the directories exist *and* are ready to use, that final step --
> creating symlinks -- can be documented in a sentence or so. [And maybe
> someone would write up a page or so of examples for true novices.]
Debian tries to promote reliability. 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.
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.
The fact that the FHS makes their existence optional, means that it's
not insisting that we install them.
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.
> 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.
> > I hestitate to even recommend creating symlinks because I've seen
> > programs that will break if not found through /opt/package/bin.
> > Ugly, maldesigned packages, true, but that's the whole thing about
> > proprietary software -- you don't get any choice in the matter.
>
> That does make the requisite documentation a bit more complex (you have
> to recommend a shell script wrapper).
>
> However, just because this is a bit complex doesn't mean that the rest
> should be.
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.
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.
> > > And, I don't see that the existence of these directories would
> > > create any problems for our users or our developers.
> >
> > I don't see it offering any measureable benefit either, and we have
> > much more important things to worry about.
>
> I see a measurable benefit: it makes the whole situation easier to talk
> about. Both in terms of documentation for admins (just create a symlink,
> with a foot note about shell script covers for broken programs), and for
> corporations who might be generating packages (want to try explaining
> why a package is broken if it doesn't work from a symlink in /opt/bin/
> when we don't even *provide* an /opt/bin/? Do you expect a corporate
> developer to "just know" about this?)
hopefully the absence of /opt/bin will provide that developer with the
hint that they are not to assume it's presence, or worse use it
internally. A corporate developer who writes an explicit path of
``/opt/bin/foo'' into their code, just wrote a bug. If instead he
writes ``/opt/bar/bin/foo'' then it will work regardless. I see it as
our responsibility to try to make sure that happens.
> > > We already have /opt/man/ in /etc/manpath.config. If we also have
> > > /opt/bin in our default path, and /opt/include preconfigured as system
> > > include files, etc. then we make it a lot easier for a novice sysadmin
> > > to integrate an /opt package with the rest of our system. There would
> > > be no need to go and change a bunch of configuration files -- all the
> > > sysadmin has to do is install some softlinks.
> >
> > Now this part of the plan I strongly approve of. Let's do this first,
> > this part is important, then we'll worry about silly hacks that the
> > people who need won't need. :-)
>
> I've already filed a wishlist bug report against bash about $PATH.
> I've not taken the time yet to figure out if info or gcc need to
> do anything.
>
> Once again: I see a need for these directories as a simple form of
> documentation.
Since you admit that actual documentation is required anyway, why not
document their creation too.
As far as $PATH goes, where does it go in the path ?
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.
On the other hand, if we were to put /opt/bin at the front, what
happens when some ISV idiot a) creates a package that automatically
installs the /opt/bin links, and b) includes a name conflicting
binary, ``ls'' say.
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.
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.
By creating it in advance we are giving a strong hint that using
/opt/bin is the right thing to do, and quite often it simply is not.
You keep claiming that it's specified in the FHS for a reason, but I
would like to point out that it specified as optional for very good
reasons too. Obviously they have to mention it in the FHS, because
otherwise some idiot at ``Multiuser Access Networking Inc.'' would
decide to put all their packages under /opt/man, that doesn't mean we
actually need to create the directory in advance.
Cheers, Phil.
P.S. I think I just made up Multiuser Access Networking Inc. If they
actually exist, no insult was intended ;-)
Reply to: