(Jul 12 2005 09:57) Brunello Ivan wrote: > Ajith, Thank you for the suggestion. > I'll try to look & understand better, before blindly applying this. > It is hard for my current packaging capabilities. > (regex & perl are still quite a nightmare to me). > > > To answer your question, Chris: > > I provide the full time-modules package, w/ all the current included > modules. It is not my intention to remove modules from a cpan > tarball, or even remove "provides" from a package. > > But the package depending on this (let's call it e.g. "nmis") just > require Time::ParseDate. Whenever the time-modules changes (maybe > splitting), I wish to ensure that nmis package still checks for perl > module, and not the whole package.
RPM already handles this automatically: [EMAIL PROTECTED] ~# rpm -q --requires perl-xml-rss perl = 5.8.5 perl(XML::Parser) perl(Test::Manifest) rpmlib(VersionedDependencies) <= 3.0.3-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 /usr/bin/perl [EMAIL PROTECTED] ~# rpm -q --whatprovides 'perl(XML::Parser)' perl-xml-parser-2.34-1tr So by not adding any requirements on "XML::Parser" or "perl-xml-parser" in the spec file, you can be sure that rpm will figure out that "XML::Parser" is indeed needed, and that swup will figure out what package provides "XML::Parser" and install that one. > > If I just need /bin/ls, I would prefer to put "/bin/ls", not the whole > "coreutils" in Requires. If /bin/ls is provided by either "fileutils" > or "coreutils" does not matter to me. This is fine until a file moves. It's not likely that 'ls' will move, but sometimes stuff do move, and you have the same problem all over again. It's best to let rpm handle most of the dependencies internally. > In short: > My goal is adding granularity to requirements checks in depending package, > not to reduce provided features. > > I hope this has cleared my intentions :-) Sure did. Hope my introduction to rpm resource management helped in that respect. c -- Christian H. Toldnes Trustix Developer _______________________________________________ tsl-discuss mailing list [email protected] http://lists.trustix.org/mailman/listinfo/tsl-discuss
