On Wednesday, 27 February 2008 at 02:23, John Dennis wrote: > Historically when a package includes optional support via a loadable module > we've put the loadable module in a subpackage. For example a package might > include a module supporting mysql so we would create a mysql subpackage > which contains the mysql loadable module and the subpackage would require > mysql. I presume the reason we've historically created these little > subpackages is to deal with dependency issues. > > But suppose your package includes dozens of optional loadable modules does > it still make sense to create dozens of subpackages? IMHO it does make sense. I know disk space is cheap, but still I prefer to keep my system free of any unnecessary stuff. > It starts to get unwieldly really quick. What exactly is the problem? > Is it permissible to skip all the subpackages, have > the rpm include all the loadable modules, and put the onus on the user such > that if they edit the main package's config file to load the mysql module > it's up to them to make sure the mysql libraries are installed? > > Here's another issue: Suppose the package puts it's loadable modules (e.g. > .so's) in it's own subdirectory for loadable modules. RPM's automatic > dependency checking seems to completely miss all the external libraries > needed at run time to load one of the modules and resolve all it's > references. The net result is none of these external dependencies get > picked up at all. Is that O.K.? How does one deal with that in a spec file? > The answer to this question probably drives the answer to the first > question. I find it odd that it doesn't find the dependencies on external libraries. Could you show the package to us? It may be a bug in the dependency generator. > FWIW, the upstream spec file does not create a subpackage per loadable > module. It does create a subpackage containing all the loadable modules. > When we build the loadable module subpackage the resulting rpm is missing a > lot of the external dependencies on external .so's. That's unfortunate but > I'm thinking it's the only practical way to deal with it. Trying to factor > out all the dependencies will be a packaging nightmare and it's going to be > a headache for users trying to install, they're going to have to deal with > lots of subpackages. At least with the scheme where all the loadable > modules are in one subpackage you won't pull in stuff you don't want or > need, but at the expense of not pulling in something you might need. > Comments? Well, without seeing the package, it's difficult to comment on this. I still think it's desirable to split the parts that require additional external libraries as much as possible. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
