> On Fri, 24 May 2002, Eli Segal wrote:
>
> > I install there all the optional software, espacially the one with the
> > sources ...
> > then, when i want to format and install everything or just to erase some
> > package
> > i can do it easily without loosing anything
>
> /opt/pckagename is intended to give a separate name space to seeprate
> packages. For instance, suppose want to have both KDE2 and KDE3 on the
> same system. If you have originally thought you may want to do that, you'd
> place QT and KDE under /opt/kde[23] (This is what SuSE does, IIRC).
>
> But for a relatively small, RPM-packaged, package this seems pointless.
> Recall that it is easy to remove such a package (unless you have
> problematic pre/post scripts. Those scripts should not be normally used,
> as a rule of thumb). You also need to add it to your PATH LD_LIBRARY_PATH
> (or ld.so.conf), MANPATH (or man's conf) and watever.
>
> I personally place RPM-based packages under /usr .
>
The FHS explicitly states that local packages should be placed in
/usr/local or /opt. The rational is that a packaging system like deb or
rpm has the freedom to do whatever it wants in /usr. /usr/local and
/opt are shielded from this freedom. As a result I believe that tar
balls should be installed in /usr/local or /opt. Yet I wonder
1. Whether an RPM that is put on the net can be considered a local
package.
2. Whether it is desirable to put a package that uses the packaging
system
services outside the central control of the packaging system.
Maybe the test for RPMs should be the long time support: Only when the
packager intend to support the package for a long time then it should
be put in /usr.
As for avoiding using the pre/post scripts there are many situations
where there is not much choice. For example, when removing a daemon
package you want to remove the service in a clean manner before
actually removing it. In addition, due to the fact that creating those
scripts makes the packaging process somewhat more complicated I would
say that packagers will not use those scripts unless they have to.
--
Shaul Karl, [EMAIL PROTECTED] e t
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
