Fedora Core 1 Test Update: spamassassin-2.63-0.1

[Michael Schwendt]

On Wed, 11 Feb 2004 00:18:57 -1000, Warren Togami wrote:

> 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?

Did you say "most robust"? Then let's roll this up from the bottom to see
what options there are. Depending on privlib, which would create a
dependence on a specific version of Perl, would break as soon as Perl is
updated to 5.8.2 or downgraded to 5.8.0. I wouldn't call that "robust".

The spamassassin package installs perl stuff into a versioned vendor path.
That makes it depend on a Perl version (5.8.1) as well as the availability
of the versioned vendor directory in Perl's search path. See bottom of
"perl -V | grep -A50 INC". One can see that spamassassin built for Perl
5.8.0 need not be rebuilt for Perl 5.8.1, because the 5.8.0 vendor dirs
are in the search path of Perl 5.8.1, too. So, you could determine the
exact Perl version and depend on it at build-time, e.g. as in the stock
Yarrow package, perl >= 3:5.8.1 for your update, assuming that vendor
locations don't change with future releases of the Perl 5.8.1 package. But
as long as the main Perl package does not provide the vendor directories,
which it supports in @INC, how do you know whether Perl 5.8.2 will still
search for modules in the 5.8.1 vendor locations too, if you cannot depend
on those directories? For instance, Perl 5.6.1 does not search in 5.6.0
site/vendor locations, although minor releases should not break
binary/source compatibility.

Somewhat "robust", but still a hack, might be to depend on $sitelib

  $ rpm -qf /usr/lib/perl5/site_perl/5.8.1
  perl-5.8.1-92

  $ perl -V:sitelib
  sitelib='/usr/lib/perl5/site_perl/5.8.1';

but install into $vendorlib, 

  $ perl -V:vendorlib
  vendorlib='/usr/lib/perl5/vendor_perl/5.8.1';

assuming that when $sitelib changes, $vendorlib changes similarly. And if
Perl 5.8.2 searches in 5.8.1 and 5.8.0 site locations, it will still
search in 5.8.1/5.8.0 vendor locations, too.

FC2 package could depend on $vendorlib directly, of course. Though, needs
to be checked whether FC2 Perl package provides the older 5.8.1 and 5.8.0
vendor/site locations, too, when they are in @INC.

> Should we own the 
> directories in spamassassin, like we do with fedora.us perl modules? 
> Opinions please.

What's worse? Not owning directories? Leaves empty directories upon
package removal and can create inaccessible directories when admin has a
restrictive umask. Or making multiple packages own the directories as a
work-around? Creates the problem you've run into, that an unexpected
package resolves a dependency.

--