On Fri, 24 May 2002, Shaul Karl wrote: > > 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.
FSH standards/recomendations are for those who distribute systems. when I build my own system/systems I make my own rules, and I am free to adopt whatever part of the standards I chose. (This does not mean that I disrespect the standards, please read on) > Yet I wonder > 1. Whether an RPM that is put on the net can be considered a local > package. A good question. I tend to label my home-made packages with a revision number label of "local" (instead of the "mdk" as used by Mandrake). Therefore I know that those are my own packages. An rpm I downloaded "from the net" is something I try to inspect before installing. Expcially its installation (and uninstallation!) scripts, because there is no automatic verification of those. > 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. Since I don't have apt, and currently urpmi doesn't work well for me, that point is not relevant. I have no choice but to rely on the packages dependencies, and on my memory... > > 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. However, in most cases you do have a choice. If you can do it in the %install script: do it there. If you think you can't: try thinking harder ;-) > In addition, due to the fact that creating those > scripts makesthe packaging process somewhat more complicated I would > say that packagers will not use those scripts unless they have to. > -- Tzafrir Cohen mailto:[EMAIL PROTECTED] http://www.technion.ac.il/~tzafrir ================================================================= 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]
