On Apr 17, 2006, at 11:07 AM, James Olin Oden wrote:
<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.
Multiply owned directories work just fine afaik. Certainly did when I
implemented in RHL 7.0.
The issue is attaching metadata, like file contexts, owners, perms to
directories
reliably. Forcing directories to be provided by some package, even if
not
the Compress::Zlib package, is the goal, as rpm already reliably handles
all the details of setting and verifying directories from package
metadata.
Setting up the infrastructure to attach contexts/owners/perms for
orphan directories
is a waste of time imho. Sure root.root 755 with SELinux policy-of-
the-day has
"worked" as a sane default so far.
Except for the occaisional bug, as you know ;-)
I don't think I've really answered any questions, but I do hope I have
clarified this general problem a little better.
Yep. I hope I have as well ...
73 de Jeff
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
