Re: [forward] FHS pre-2.1 draft #3 on web site
Raul Miller <moth@debian.org> writes:
> 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.
The status quo is that the directories do not exist. You have to show
that their existence will provide a net benefit in order to justify a
change to the status quo.
The benefit of FHS compliance would seem to justify the creation of
/opt, but since there is nothing in the FHS about the need to create
the other sub-directories, they need to be justified on their own
merits.
You claim that not installing them doesn't solve any problems. What
problems? There are several problems with including them IMO (which
I've mentioned before and below), but I don't see any that are solved
by the creation of the directories, other that the `problem' of typing:
mkdir /opt/{bin,doc,include,info,lib,man}
Big deal.
> > 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.
I don't see that there is any requirement to add any symlinks to
/opt/bin, and as I have explained, I would not do so, and would expect
that doing so would store up problems for the future.
Why should we make it easier for people to do something stupid,
especially when the people in question are inexperienced sysadmins who
wouldn't know better until it was too late.
> > > 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/].
You've not been paying attention. I've mentioned several reasons.,
the most important of which is:
Clueless ISV programmers are likely to take their existence as an
encouragement to use them, probably by brokenly installing symlinks
there, and perhaps committing the more serious mistake of making their
code rely on those links.
You on the other hand don't seem to have come up with any
justifications for their inclusion, beyond:
They are mentioned in passing in the FHS [as something that ISVs
should not touch, I must point out].
It would save people a single command when installing their first
/opt package [invalid, since some people will not want to create
these directories, and might actually be forced to run an extra
command in order to remove them]
You claim that ISV's will not write code for Debian if we don't put
/opt/bin in the path. [invalid, given that ISV's are explicitly
forbidden from relying upon the existence of these directories in the
FHS]
Without a good reason for creating them, they should be left out.
> > 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.
It is possible that the very first thing you put in /opt/bin will have
one of these problems, so I don't really see the point you are trying
to make.
> > 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...]
I'd imagine that LSB will include /opt and nothing more, in order to
be FHS compliant. Why don't we try that too? ;-)
> > 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).
I have no idea, since I just made it up, and such considerations are
totally irrelevant, since you will no longer be running the one from
any version of oracle in the hypothetical example I just conjured up.
Cheers, Phil.
Reply to: