Fedora Core 1 Test Update: spamassassin-2.63-0.1

Randal, Phil prandal at herefordshire.gov.uk
Wed Feb 11 11:42:25 UTC 2004


Is this not a bit of overkill for FC1?

I rolled my own spamassassin-2.63 RPM by basically rebuilding FC1's
spamassassin-2.60 RPM with the SA 2.63 tar.gz file.

If what we had was adequate for FC1, why not the same approach for the
update?

And sort it out properly for FC2?

Cheers,

Phil

---------------------------------------------
Phil Randal
Network Engineer
Herefordshire Council
Hereford, UK 

> -----Original Message-----
> From: fedora-test-list-admin at redhat.com
> [mailto:fedora-test-list-admin at redhat.com]On Behalf Of Warren Togami
> Sent: 11 February 2004 10:19
> To: fedora-test-list at redhat.com; Chip Turner; Ville Skyttä
> Subject: 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 at 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 at laptop root]# rpm -q perl
> > perl-5.8.1-92
> > [root at 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 at laptop root]# rpm -ivh spamassassin-2.60-2.i386.rpm
> > Preparing...                
> ########################################### 
> > [100%]
> >    1:spamassassin           
> ########################################### 
> > [100%]
> > [root at 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 at 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
> 
> 
> -- 
> fedora-test-list mailing list
> fedora-test-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-test-list
> 





More information about the test mailing list