<snip> > The correct thing to do is Provide: the parent directories somehow. > > The quick and dirty fix to provide all missing directories > immediately is to > run (with 4.4.6) > > rpm -Va --nofiles | grep -v "Unsatisfied" | sort -u > /etc/rpm/ > sysinfo > > (Note: you'll have to eyeball or edit the list of paths to taste.) > > (Also note: /etc/rpm/sysinfo contains system Provides: because only a > few > people ever figured out virtual packages. So back to the Good Old Stuff, > but now with dependency ranges). > > That will Provide: all those paths. > > A better fix is to add all those paths to another package so that the > directories are removed. > > In the specific case you mention here, I'd "own" the directory in > Compress::Zlib. Which is not the right thing to do, because there are other modules that live in the Compress directory (such as bzip2). This is a pretty common situation that occurs. For instance the $perllibdir/File directory has oodles of different modules that get dropped in there. I think probably what I would do in his case is create something that examines the perl package, and the different perl module packages and figures out what directories under the libdirs need to exist and generate a package that delivers those missing directories. I'm not sure if this is the best solution though. Basically, the general problem not limited to perl is when namespacing of libraries is mapped onto the filesystem. Since multiple libs can live in the same namespace/directory none of these libs should own the directory. If not one of them, though, who should own it? In perl's case you could argue that perl could own all those directories, but that falls apart as soon as someone adds a new module name space; also, typically not every possible module in the universe of modules (a.k.a. cpan) is installed on any given system, so do you premditatedly create these directories in the host language's package even though no libraries may be dropped in there? If multiple packages could own the same directory (which this used to be doable) this is resolved (though I don't like it aesthetically), then all libs that are dropped into a particular directory own the directory. This works for erasures too, as when the first module that lives in that dir is removed, the directory stays because files are still in it. When nth module is removed, provided the directory is empty, the directory gets removed. I don't think I've really answered any questions, but I do hope I have clarified this general problem a little better. Cheers...james > > > How others are handling this situation? Have every RPM claim it owns > > the top of the namespace it's in and down? > > > > hth > > 73 de Jeff > > _______________________________________________ > Rpm-list mailing list > Rpm-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/rpm-list > _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
