[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora Core 1 Test Update: spamassassin-2.63-0.1



Warren Togami wrote:
Michael Schwendt wrote:

On Wed, 11 Feb 2004 08:14:02 +0100, shrek-m gmx de wrote:


# rpm -q spamassassin spamassassin-2.60-2

# rpm -Uvh /mnt/sda1/updates/download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/1/i386/spamassassin-2.63-0.1.i386.rpm

Fehler: Failed dependencies:
/usr/lib/perl5/vendor_perl/5.8.1 is needed by spamassassin-2.63-0.1


# rpm -q perl
perl-5.8.1-92


is --nodeps needed ??



No. An updated test update package will be needed to fix this, as on FC1:


  $rpm --redhatprovides /usr/lib/perl5/vendor_perl/5.8.1
  file /usr/lib/perl5/vendor_perl/5.8.1 is not owned by any package

A future Perl package will own more directories and also the vendor
locations. So, presently, an FC1 test update must not and cannot depend on
that directory.



[root laptop root]# rpm -q perl
perl-5.8.1-92
[root laptop root]# rpm --redhatprovides /usr/lib/perl5/vendor_perl/5.8.1
file /usr/lib/perl5/vendor_perl/5.8.1 is not owned by any package
[root laptop root]# rpm -ivh spamassassin-2.60-2.i386.rpm
Preparing... ########################################### [100%]
1:spamassassin ########################################### [100%]
[root laptop root]# rpm -Uvh spamassassin-2.63-0.1.i386.rpm
Preparing... ########################################### [100%]
1:spamassassin ########################################### [100%]



At first I was like "HUH?" Why does it work for me but not you... but then I found the reason.


[root laptop root]# rpm -qf /usr/lib/perl5/vendor_perl/5.8.1
perl-DateManip-5.42-0.fdr.2.a.1
perl-RPM-Specfile-1.13-0.fdr.2.1
perl-Digest-Nilsimsa-0.06-0.fdr.4.1

All perl modules provided by fedora.us seems to own this directory. So this leaves us with two questions:

1) Can someone check if this problem still exists in rawhide?
2) What should we change the Requires to for this FC1 update? I am thinking "Requires perl >= 2:5.8.0" which is like how it was before. It required rebuilding for different pre-FC2 perl versions, but that's acceptable I guess.


See the thread "perl and multilib considerations" from January where this was previously discussed. Since Chip Turner's suggestion of a virtual provides does not exist in these older perl versions, we have to use an imperfect solution. #2 above may be good enough for now.

I'll roll the next FC1 test update when I wake up Wednesday based upon comments here. Just a sanity check please.

Warren



<mschwendt> warren: Well, the current Perl package does not own the vendor directories. So including them in the spamassassin package would be cleaner, to avoid the problem of restrictive admin umask creating them with insufficient permissions. You could depend on $privlib (although you don't install into it), because that's the first directory owned by "perl" which is versioned.
<warren> mschwendt: it seems that the fedora.us perl modules own that directory too
<mschwendt> warren: fedora.us perl packages own them to avoid the problems of leaving empty directories behind and the permissions problem
<mschwendt> warren: why do you depend on a path instead of "perl = 3:5.8.1"?
<warren> mschwendt: (got the idea from mharris xchat spec, I thought that too was correct but now I believe it has the same problem that we see here)
<warren> mschwendt: I thought it was working until this discovery, and we had a thread discussing it late January
<warren> mschwendt: Chip Turner's solution creating a standard virtual provides sounded like the best solution for FC2+, but I thought this solution was working in FC1. I was wrong. It only worked while I had fedora.us perl modules installed.
<mschwendt> warren: hmmm, stock spamassassin in Yarrow depends on "perl >= 2:5.8.0" which is bad.
<warren> yes, the old method was bad, but it generally worked as long as your sources weren't broken
<mschwendt> warren: that's why it is unfortunate that fedora.us packages must work around unowned directories by owning them. Creates problems like this.


Okay so... bottom line:
FC1's perl package unfortunately means we must use ownership with module packages in order to avoid unown directories and associated problems (like unable to strip binaries). While this situation can be easily remedied in FC2's perl so we no longer need this hack, we need the most robust solution for now.


Without Chip's suggestion of virtual Provides in place, what Requires line should go into this spamassassin FC1 update? Should we own the directories in spamassassin, like we do with fedora.us perl modules? Opinions please.

Warren




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]