marks wrote: > Two files specifically come to mind. /etc/[rc.d]/init.d/[prod] and I would think that file could just be packaged up and marked with "%config" doing normal things. > /lib/modules/`uname -r`/misc/streams-[prod].ko (on 2.6 kernels). Building a kernel module on the fly. Wow. I think you might be blazing a trail. For kernel modules it would be much better to get the module pushed upstream into the kernel sources proper. That way it will "just work" for people on a variety of hardware and you would not need to worry about packaging it separately. > 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. If the rpm is simply a facade and I think that is the best that you can do here then I think it would be better to leave it off. I would be representative of one of your customers that would request the files to be installed by rpm. But if I was delivered something that was an rpm in name only but really just used "tricks" to make it fit in then I would not be happy about it. I think your customers might actually be less happy with a facade than without one. Saying 'rpm' implies more than just 'rpm --install file.rpm'. See rule 13.1.3. http://fedora.redhat.com/docs/drafts/rpm-guide-en/ch-packaging-guidelines.html#id2994388 > 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. So just to play devil's advocate, how would your package react when a new kernel is installed? Would it register a trigger of some sort to detect this and to build a new kernel module on the fly for it? Trying to handle this just seems like trouble. About the best idea that I might suggest is to distribute a script that the local admin could run that would build the module and other files against the specific kernel and have it produce an rpm that could be installed. Then as new kernels were installed the end user could run the script to build the new modules and then install the result by rpm. Then the rpm could be the real deal. > > +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). I would be surprised if anything that is not a museum piece does not have /etc/init.d these days. > SuSE did support chkconfig for a while but at some point (9.3? 10.0?) > removed it in favor of insserv. I am behind in my knowledge of recent SuSE systems. I will need to research that system. > MontaVista uses update-rc.d but I have not even tried our rpm on > that platform as of yet. When you said update-rc.d I assumed Debian/Ubuntu which uses it. > Can you recommend a good resource for learning more about .spec files > (i.e. use of %ghost)? https://lists.dulug.duke.edu/pipermail/rpm-devel/2005-April/000405.html And in general. http://fedora.redhat.com/docs/drafts/rpm-guide-en/index.html Bob _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
