Re: FHS, macros, and Pinstripe

["Kenneth Porter" <shiva well com>]

On Fri, 1 Sep 2000 14:42:46 -0400, Jim Knoble wrote:

>Best would be to add the proper configuration to both spots.  Then, for
>example, if the admin switches from inetd to xinetd after the daemon's
>package is installed, the daemon's xinetd config is already there.

Good point. I have no experience with xinetd, but it sounds like it's
more "package-friendly" by not requiring client packages to modify its
primary config file. My qpopper package does not install its line in
inetd.conf out of my own paranoia at screwing up someone's config.

>This is generally a packaging policy that varies with distributions and
>with packagers.  I don't always want inetd/xinetd restarted when i
>install or uninstall a package---for example, if i'm installing a
>package so that i can read the documentation to figure out whether i
>want the service there or not, i don't want the service started without
>my knowledge.  Or perhaps the service won't be secure until i configure
>it properly.  The granularity of rpm --install --no-scripts is,
>unfortunately, usually too coarse to allow for such situations.

Yes! I just ran into this with pmfirewall: Its installation script
insists on being root *before* writing its ipchains script. I figured
it would be nice to run the part that simply writes an ipchains script
as a normal user, and then inspect the result, but I'd have to hack its
configuration/installation script to do that.

Speaking of installing just to read documentation, is there an RPM
switch to just install the %doc files? (I had the misfortune the other
day of installing a Windows app that complained that it couldn't be
installed due to a DLL incompatibility, and it told me to check the
readme for a workaround. Of course, the readme isn't available until
the program is installed! Fortunately I discovered a support newsgroup
for the product that had an answer.)

Ken
mailto:shiva@well.com
http://www.sewingwitch.com/ken/
http://www.harrybrowne2000.org/