[JANITOR] Duplicate directory ownership cleanups

[Panu Matilainen]

On Fri, 26 Jun 2009, Chris Weyl wrote:

> 
> 
> On Fri, Jun 26, 2009 at 11:48 AM, Chris Weyl <cweyl at alumni.drew.edu> wrote:
> On Fri, Jun 26, 2009 at 9:29 AM, Jussi Lehtola
> <jussilehtola at fedoraproject.org> wrote:
>       On Fri, 2009-06-26 at 18:07 +0200, Iain Arnell wrote:
>       > okay, not actually broken, but this is definitely
>       messing with (some
>       > of the) perl structure (and
>       perl-DBIx-Class-EncodedColumn already
>       > requires perl-DbIx-Class). What gives?
>       >
> > diff -u -p -r1.1 -r1.2
> > --- perl-DBIx-Class-EncodedColumn.spec  10 May 2009 06:54:10
> -0000      1.1
> > +++ perl-DBIx-Class-EncodedColumn.spec  26 Jun 2009 09:12:21
> -0000      1.2
> > @@ -1,6 +1,6 @@
> >  Name:           perl-DBIx-Class-EncodedColumn
> >  Version:        0.00002
> > -Release:        1%{?dist}
> > +Release:        2%{?dist}
> >  Summary:        Automatically encode columns
> >  License:        GPL+ or Artistic
> >  Group:          Development/Libraries
> > @@ -55,10 +55,13 @@ rm -rf $RPM_BUILD_ROOT
> >  %files
> >  %defattr(-,root,root,-)
> >  %doc Changes README
> > -%{perl_vendorlib}/*
> > +%{perl_vendorlib}/DBIx/Class/*
> >  %{_mandir}/man3/*
> 
> This was clearly a duplicate ownership issue which spot dealt
> with
> correctly. perl-DBIx-Class already owns
>  %{perl_vendorlib}/DBIx/Class/
> and thus there is no need for perl-DBIx-Class-EncodedColumn to
> own the
> directory since it requires perl-DBIx-Class (which owns the
> directory).
> 
> 
> Ian and Ralf are absolutely correct here.  perl-* packages have for
> years operated under the convention and explicit guideline that
> anything we deliver under %{perl_vendorlib} or %{perl_vendorarch} must
> be owned by the package providing it.
> 
> The canonical example here generally involves differing vendorarch/lib
> dirs, as they're versioned by Perl. E.g. if perl-DBIx-Class was built
> under 5.10.0, it's going to put its bits under
> /usr/lib/perl5/vendor_perl/5.10.0.  In the meantime if we go to Perl
> 5.10.1 and build perl-DBIx-Class-EncodedColumn under that level, it
> will use /usr/lib/perl5/vendor_perl/5.10.1 as its directory... leaving
> /usr/lib/perl5/vendor_perl/5.10.0/DBIx/Class/ unowned.
> 
>  
> ...or, if XS (arch-specific) bits were added to perl-DBIx-Class (which isn't
> terribly unlikely), all of a sudden it would be using directories under
> /usr/lib64/perl5/vendor_perl/5.10.0/x86_64-linux-thread-multi, not
> /usr/lib/perl5/vendor_perl/5.10.0...  Also hosing directory ownership. 
> (noarch/arch changes like this are rare, but hardly uncommon.)
> 
> Another, perhaps clearer way of saying this is: 
> perl-DBIx-Class-EncodedColumn will require perl-DBIx-Class through the
> virtual perl provide of perl(DBIx::Class); yet requiring perl(DBIx::Class)
> does not guarantee that any particular directory under Perl lib paths (@INC)
> will be created and owned.
> 
> Perl requires are managed through the perl(*) set of virtual provides. 
> Depending on a certain perl(*) provide to own specific directories is risky
> at best, and a mess towards its worst.  The only sane, clean and consistent
> way to deal with this is for each perl-* package to own everything it
> provides.

Other than "what a mess" :) ... yes this is fine and harmless from rpm 
POV. It's the entirely silly cases like these (just a random sampling 
from the big big list to make the point hopefully clear) I'd like to see 
weeded out:

multiprovided dir /usr/share/man/man1
   -> filesystem-2.4.21-1.fc11.x86_64
   -> gnome-power-manager-2.26.1-3.fc11.x86_64
   -> policycoreutils-2.0.62-12.6.fc11.x86_64
multiprovided dir /usr/share/man/man8
   -> filesystem-2.4.21-1.fc11.x86_64
   -> policycoreutils-2.0.62-12.6.fc11.x86_64
   -> selinux-policy-3.6.12-39.fc11.noarch
multiprovided dir /usr/share/applications
   -> filesystem-2.4.21-1.fc11.x86_64
   -> system-config-httpd-5:1.4.4-4.fc11.noarch
   -> xsane-0.996-7.fc11.x86_64
multiprovided dir /usr/share/locale/es/LC_MESSAGES
   -> avahi-0.6.25-1.fc11.x86_64
   -> filesystem-2.4.21-1.fc11.x86_64
   -> glibc-common-2.10.1-2.x86_64
   -> kde-i18n-Spanish-1:3.5.10-4.fc11.noarch
   -> kde-l10n-Spanish-4.2.2-1.fc11.noarch

Practically all packages will end up having a relation to filesystem 
anyway, so most likely no information lost if the cases like above are 
simply ignored. But consider this:

multiprovided dir /usr/lib64/pkgconfig
   -> freetype-devel-2.3.9-3.fc11.x86_64
   -> libXScrnSaver-devel-1.1.3-2.fc11.x86_64
   -> pkgconfig-1:0.23-8.fc11.x86_64

Quite clearly pkgconfig should be the only owner of that directory, and 
this is a lost opportunity to automatically do the right thing in ordering 
based on just the directory information.

 	- Panu -