On Fri, Jun 26, 2009 at 9:29 AM, Jussi Lehtola <jussilehtola@xxxxxxxxxxxxxxxxx> wrote:
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.
This convention has worked very well for us in the Perl world/SIG, and has been hashed through way past death ages ago. Absent a compelling reason ("it breaks rpm!") I can't imagine what we'd gain from it.
-Chris
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.2This was clearly a duplicate ownership issue which spot dealt with
> --- 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/*
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.
This convention has worked very well for us in the Perl world/SIG, and has been hashed through way past death ages ago. Absent a compelling reason ("it breaks rpm!") I can't imagine what we'd gain from it.
-Chris
--
Chris Weyl
Ex astris, scientia
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
