Jeff Johnson wrote: > marks wrote: > > When installing the rpm, is it expected that every file installed > > or generated when running "rpm -i" be owned (rpm -qf) by the > > package? > > In general, yes, almost all files should come from the package, not > side effects. Mostly agreed. I think all files should be packaged. But in order to handle configuration files specifically I do often leave files from /etc/* unpackaged and managed manually in the scripts. But generally speaking all files should be packaged. After an installation everything should verify cleanly (i.e. that rpm --verify should be clean). > > If so, how do I get files that are built on the fly by the > > scriptlets in the rpm to show in the rpm database as owned by the > > package (rpm -qf}? What files are you trying to build on the fly? It sounds somewhat unusual to be needing to do that and so I wonder if there isn't an alternative to what you are trying to do. > > Also, the rpm I am developing will hopefully support all our > > currently supported 2.4 and 2.6 kernels regardless of linux vendor > > (redhat, SuSE, MontaVista, etc.). In what way does the kernel affect your package? If you are installing something that is kernel specific such as a kernel module then I think you will need to make it kernel version specific. And if not then it should not matter at all what kernel is on the machine. The kernel interfaces between libraries and the hardware. The libraries interface between the kernel and your applications. You should be concerned about library versions but you should *not* be concerned about kernel versions, in the majority of cases. > > What mechanism do people use to determine where to install an > > init.d startup script (/etc/init.d, /etc/rc.d/init.d, etc.)? > > The FHS standard is /etc/init.d iirc +1. I would simply use /etc/init.d/foo and whine along with the rest of us when vendors do not follow the FHS. > > Each linux vendor seems to have a different location for the > > init.d directory. I do know that many vendors include a symlinked > > /etc/ init.d directory that points to their actual init.d > > directory but I'd rather not use that as a crutch. This is not really a crutch. It is a compatibility layer that has been chosen by the vendor to be able to be backward compatible to their previous versions and also maintain compatibility with new applications following the standards. > > Then of course I have to deal with all the different vendor > > utilities for managing init.d scripts (chkconfig, insserv, > > update-init.d, etc.). > > There's a standard using chkconfig and comments in the init scripts > iirc, but perhaps I've spent too long with RH linux. I think if you are building an rpm then you would use chkconfig. (The others such as update-rc.d that you mentioned would be for building other types of packages for other distros.) I suggest that you use 'chkconfig --add $packagename' in the %post script and define the runlevels properly in the init.d script. Unfortunately there is no standard policy document for rpm based systems defining how applications should interface. So it is mostly a free for all. Having a defined policy is where some of the other distros have a clear advantage. Bob _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
