Hi Tim!
On Apr 16, 2006, at 3:08 AM, Tim Mooney wrote:
Let's say you want to package a perl module like Compress::Zlib as an
RPM. You have your spec file set up (yes, I know about Mezzanine and
cpanflute2) and your %files section looks like this:
%files
%defattr(-,%{OWNER},%{GROUP})
%{SITE_PERL}/%{PERL_FULL_VERSION}/%{ARCHDIR}/auto/Compress/Zlib
%{SITE_PERL}/%{PERL_FULL_VERSION}/%{ARCHDIR}/Compress/Zlib.pm
%{PERL_MAN_ROOT}/man3/Compress::Zlib.3*
Assume that OWNER, GROUP, SITE_PERL, PERL_FULL_VERSION, ARCHDIR, and
PERL_MAN_ROOT are all defined to reasonable values previously in
the spec
file.
The thing to note is that this RPM doesn't claim ownership of the
auto/Compress directory or the Compress directory -- only the Zlib
directories
(and contents) underneath them. This is what I intended. We've used
this type of thing for years with an ancient version of RPM
(2.5.6), and
more recently on Red Hat AS 3 and AS 4 with the version of RPM
that's included
with them.
Yep.
Not specifiying the directory is a very common and somewhat subtle
packaging error.
If that's what you the packager inntended, it makes no sense to
expect rpm, rather than you,
to "claim ownership" of the parent directory.
Sure rpm will create the directory in order to install the file, it's
"ownership"
and "intended" that are at issue, not "existence" or "creation".
Perhaps the
best way to explain the difference is by asking
Who erases the directory?
but there are other issues with user/group, permissions, and extended
attributes
that are tied to establishing "ownership" of the orphaned directories
are more
important than answering who erases the directory.
I've been experimenting with rpm 4.4.5 and now 4.4.6 on my Solaris
workstation, and I discovered that this type of construct no longer
works,
because RPM wants something to provide the "Compress" directories,
and nothing
currently is, so it's giving the "Failed dependencies" error when I
try
and install the RPM that I build from this spec file.
Hmmm, a few details:
1) 4.4.6 has different behavior, not 4.4.5, synthesizing a
Requires: for all parent dirs.
2) installation of unowned directories still "work" (sic) exactly
as always.
What is different is that every file now Requires: its parent
directory to be Provide:'d.
So what's the right thing to do here? "Lie" in the %files section of
Compress::Zlib (and any other Compress::* modules that might be
installed)
and claim that the module owns the Compress directory? The logical
outcome
of that is that nearly every perl module RPM that's part of a
particular perl
"namespace" (like HTML::, Digest::, XML::, etc.) is going to need
to claim
that it owns the top directories for that namespace. In some cases
(Digest::Base) there's a clear candidate for ownership of the top
directory,
but in many there's not.
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.
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
