proposal: @INC array change

[Stepan Kasal]

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