[JANITOR] Duplicate directory ownership cleanups

[Chris Weyl]

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.

                                           -Chris

-- 
Chris Weyl
Ex astris, scientia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090626/6526ddaa/attachment.htm>