On Wed, Feb 02, 2011 at 10:43:10AM +0000, Paul Howarth wrote: > However, the plan envisages third-party repositories sticking with > vendor directories and I'm not sure that's going to happen. If I need a > module for my own repository and Fedora already has some version of it, > I just grab that version, update it as necessary and built it. So I'll > inherit the use of the perl/core directories unless I explicitly revert > back to vendor directories. Other repositories might also want to > maintain as close compatibility with Fedora as possible and would use > that as justification for using perl/core too. > We should not assume anything about third-party repositories. Neither how they write their spec files (if any), nor if they are compatible. This is the reason why I think reserving a directory just for that purpose is good idea. Third party (= not provided by Fedora) modules should be allowed to do what they wish and distribution should not create obstacles. I think it's better to make Fedora more versatile than to burden developers of unoffical distribution extenstions. > I thought the conventional structure of having modules bundled with perl > (the perl core) going to perl/core directories and everything else > that's packaged (including dual lived modules) going to vendor > directories made good, intuitive sense, and I think that's what upstream > intended too. Dual-lived modules. That's another problem: Having them in the same directory as core modules allows packager to discover clashes sooner than at run time because RPM warns you that new package tries to overwrite file owned by another package. Also administrator gets sure there is no remaining code from original module. This is especially important when fixing security bugs. On the other hand, RPM has problem with architecture specific dual-lived packages. The problem is debuging data for all sub-packages are distributed in one package. Thus once you install perl-debuginfo, you cannot install debuginfo for dual-lived package because the files are stored in the same paths. See <https://bugzilla.redhat.com/show_bug.cgi?id=664414> for more details. Installing dual-lived modules into separate paths works around this problem. So, I like the idea to clean include paths and have everything on one place. However I'm worried Fedora packaging system is not prepared for it yet. -- Petr
Attachment:
pgplgW57ugaMX.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
