On Sat, Dec 11, 2010 at 10:25:25AM +0100, Iain Arnell wrote: > On Fri, Dec 10, 2010 at 5:37 PM, Marcela Maslanova <mmaslano@xxxxxxxxxx> wrote: > > because of bug in paths (vendorarch), there will be needed > > rebuild of some packages (~1300). I choose only those > > which weren't rebuild with vendorarch in Perl. [1] > > > > I've asked for testing dist tag, so nothing will be > > broken [2]. Rebuild will start next week. > > Is there something in place to avoid the problems we had last time > with "older" packages from the rebuild tag overriding "newer" packages > in dist-f15 itself? And is a separate tag really necessary for this? I also think it's not necessary to create new build root in this case. The last buildroot override problem has been caused by incompatible perl-libs. This is not this case and atomicity of git pushes and ordering of binary package versions should cope with buildroot merge fluently. > Perl is already looking in both core and vendor directories, so there > should be no breakage due to modules installed in the "wrong" place. > See <https://bugzilla.redhat.com/show_bug.cgi?id=661697>. Marcela forgot to explain the real problem: There are packages that install private data into perl include path. If you compiled such package with install=vendor in F14, the private data got into /usr/share/perl5/ because vendor and core paths resolved into the same directory. The problem is some packages do not store absolute path at compile time. They store just the symbolic name (vendor or core) and resolve it at run-time (e.g. via Config module). If you run such package, built in F14, in F15 where vendor path points to /usr/share/perl5/perl_vendor, then the package will look it's private data in /usr/share/perl5/perl_vendor, but the files will be located in /usr/share/perl5/ in the binary package. Thus we need to recompile all binary packages survived from F14 to move their files to actual vendor path. > And I'm still not sure what the intended result is meant to be. Are > you planning to update all the specs to use privlib/archlib so that > everything ends up in the core directories? Or keeping > vendorlib/vendorarch and merely rebuilding to move the modules out of > the core directories again? > We would like to edit all spec files to switch from vendor to core in the future. But not now. Fortunatelly there is no need to hurry as properly compiled packages work regardless residing in core or vendor as you mentioned. (Except the few packages having the problem I described above). So we would like to standardize the install path in Perl guidelines first, that adjust cpanspec and rpmlint and then advise packagers to fix their specs as they touch them for other reason. In other words we are not going to change spec files in this mass rebuild. We just want to rebuild the packages to fix the current issue. Question whether to massively rewrite vendor to core install path in next massive rebuild planned for perl-5.14 is not decided yet. -- Petr
Attachment:
pgpx4KT9K11UN.pgp
Description: PGP signature
-- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/perl-devel
