<br><br><div class="gmail_quote">On Fri, Jun 26, 2009 at 11:48 AM, Chris Weyl <span dir="ltr"><<a href="mailto:cweyl@alumni.drew.edu">cweyl@alumni.drew.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div><div></div><div class="h5">On Fri, Jun 26, 2009 at 9:29 AM, Jussi Lehtola <span dir="ltr"><<a href="mailto:jussilehtola@fedoraproject.org" target="_blank">jussilehtola@fedoraproject.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Fri, 2009-06-26 at 18:07 +0200, Iain Arnell wrote:<br>
> okay, not actually broken, but this is definitely messing with (some<br>
> of the) perl structure (and perl-DBIx-Class-EncodedColumn already<br>
> requires perl-DbIx-Class). What gives?<br>
><br>
</div><div>> diff -u -p -r1.1 -r1.2<br>
> --- perl-DBIx-Class-EncodedColumn.spec 10 May 2009 06:54:10 -0000 1.1<br>
> +++ perl-DBIx-Class-EncodedColumn.spec 26 Jun 2009 09:12:21 -0000 1.2<br>
> @@ -1,6 +1,6 @@<br>
> Name: perl-DBIx-Class-EncodedColumn<br>
> Version: 0.00002<br>
> -Release: 1%{?dist}<br>
> +Release: 2%{?dist}<br>
> Summary: Automatically encode columns<br>
> License: GPL+ or Artistic<br>
> Group: Development/Libraries<br>
> @@ -55,10 +55,13 @@ rm -rf $RPM_BUILD_ROOT<br>
> %files<br>
> %defattr(-,root,root,-)<br>
> %doc Changes README<br>
> -%{perl_vendorlib}/*<br>
> +%{perl_vendorlib}/DBIx/Class/*<br>
> %{_mandir}/man3/*<br>
<br>
</div>This was clearly a duplicate ownership issue which spot dealt with<br>
correctly. perl-DBIx-Class already owns<br>
%{perl_vendorlib}/DBIx/Class/<br>
and thus there is no need for perl-DBIx-Class-EncodedColumn to own the<br>
directory since it requires perl-DBIx-Class (which owns the directory).<br>
<font color="#888888"></font></blockquote></div></div><div><br>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.<br>
<br>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/<a href="http://5.10.0." target="_blank">5.10.0.</a> 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.<br>
</div></div></blockquote><div> <br>...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/<a href="http://5.10.0.">5.10.0.</a>.. Also hosing directory ownership. (noarch/arch changes like this are rare, but hardly uncommon.)<br>
<br>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.<br>
<br>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.<br>
<br> -Chris<br></div></div><br>-- <br>Chris Weyl<br>Ex astris, scientia<br>