Good morning/afternoon, ladies and gentlemen! I've observed indications that Fedora perl's @INC array is far form optimal; this mail contais a proposed solution, and a rationale for it. Feedback welcome. The target @INC would look like this: ------------------------------------- (%_lib denotes "lib" or "lib64," depending on the architecture.) /usr/local/%_lib/perl5/5.10 - sitearch /usr/local/share/perl5/5.10 - sitelib /usr/%_lib/perl5 - vendorarch = archlib /usr/share/perl5 - vendorlib = privlib /usr/lib/perl5/site_perl - otherlibdirs . Mapping to rpm dependencies and transition period: ------------------------------------------------- This new scheme will be bound to rpm provide perl(:MODULE_COMPAT_5.10.1) This means that perl-5.10.1-1 will provide both this and perl(:MODULE_COMPAT_5.10.0), and its @INC will be a combination of this target scheme and the current one. As soon as all Fedora module packages are rebuilt against perl-5.10.1, the compatibility aids can be removed. If we are lucky, this will be completed before Fedora 12. Rationale for the target @INC: ------------------------------ 1) site* should be under /usr/local, as it is not under rpm control. We already have this. 2) Code that is not architecture dependent should be under /usr/share while architecture dependent code should go under %_libdir. 3) There is no need to put archname to the individual *arch paths; these things are handled by rpm dependencies and multilib mechanisms. This makes the individual paths in @INC list shorter. 4) Moreover, there is no need to put version name to the path either. This makes the path is constant throughout perl-5.10.x (x>1), and avoids the need to collect the huge lists of previous versions' paths (cf. perl-5.8.x packages in previous Fedora releases). This prevents the problem that @INC would get too long and perl would spend too much time stating during startup. 5) The order of the paths is "site, vendor, core," where "core" denotes archlib and privlib. This differs from upstream 5.8 and 5.10 branches that use "core, site, vendor," but it is consistent with both Fedora tradition and blead perl. For more detailed discussion, see https://bugzilla.redhat.com/show_bug.cgi?id=489221 6) The unification of vendor and core paths is something that saves another two elements in @INC. (A small patch is needed.) This might seem strange, even dangerous, but: - we cannot unset vendor*, modules ask for their values, - I was not able to see any problem with it, - a quick question on #p5p had not revealed any problem either, - it is easy to back out this: a change of core paths should have little consequences outside the perl src rpm. 7) The otherlibdirs variable is a collection of compatibility directories. Ultimately, there should be only the one directory listed above, see the promise in http://bugzilla.redhat.com/484053#c3 During the transition period, otherlibdirs is the means to achieve the compatibility with perl-5.10.0. 8) The site* paths are "semi-versioned": they contain "/5.10". Consequently, when Fedora updates to perl-5.12, the collection of site modules will no longer be used and the user will have to reinstall them. But the site collection stays during the 5.10.* life. This is a compromise solution, balancing the idea that modules should not, in theory, depend on the version of perl and the risk that any module can actually depend on a bug in a particular perl version. The end of the rationale. Acknowledments: among the several inspiration sources I'd like to mention the perl package in Debian GNU/Linux distribution, and my conversation with Tux (H. Merijn Brand) and Nicholas Clark on #p5p. As mentioned above, feedback is welcome! Happy hacking, Stepan Kasal -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl Fedora-perl-devel-list mailing list Fedora-perl-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-perl-devel-list
