Thanks, Jeff, Bob, for the replies... more inline below. On Sat, 9 Dec 2006, Bob Proulx wrote: > Date: Sat, 9 Dec 2006 00:08:32 -0700 > From: Bob Proulx <bob@xxxxxxxxxx> > Reply-To: RPM Package Manager <rpm-list@xxxxxxxxxx> > To: rpm-list@xxxxxxxxxx > Subject: Re: rpm expectations/conventions > > 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. Two files specifically come to mind. /etc/[rc.d]/init.d/[prod] and /lib/modules/`uname -r`/misc/streams-[prod].ko (on 2.6 kernels). > > > > 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. Our package contains a kernel loadable module. We use streams (seperately installed) as a wrapper between the kernel and the module. This allows us to deliver a single 32bit package for all 32bit kernels and a seperate 64bit package for 64bit kernels. If the kernel is 2.6, the package converts the .o kernel object to .ko using the modutils of the kernel source. Our products support dozens of operating systems and we have a new requirement to deliver using rpm. I'd rather maintain our one package fits all paradigm then to have to build dozens of different rpm packages. Experience shows that customers will change their kernel version fairly often (and sometimes even the OS vendor) so I'd rather not have to keep building new rpm packages everytime a customer makes a change. > > > > 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. Heh. Unfortunately our customers won't want to wait for us to whine to an operating system vendor to fix their OS. That being said, I'll check all the operating systems that support rpm to see if they all have an /etc/init.d (whether or not it's a symlink). > > > > 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. SuSE did support chkconfig for a while but at some point (9.3? 10.0?) removed it in favor of insserv. MontaVista uses update-rc.d but I have not even tried our rpm on that platform as of yet. I've already got a single rpm built on SuSE 9.3 32bit that works on other versions of SuSE and at least two versions of Red Hat (EL3 and EL4). I've also tested the 64bit version of this rpm on both SuSE 9.3 and RHEL4. I'm now in the polishing stages, thus the questions I posed originally. Can you recommend a good resource for learning more about .spec files (i.e. use of %ghost)? Also, when is a comment not a comment? When it's in a spec file. :-) Apparently: %define myvar myvalue Is the same as: # %define myvar myvalue I've taken to removing the % symbol in a commented out define line in the .spec file in order to really comment out the define. Is this expected behavior? > > Bob > > _______________________________________________ > Rpm-list mailing list > Rpm-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/rpm-list > -- Thanks, Mark Sincerbox Adax, Inc. 1-510-548-7047 x129 _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
