Joseph Kowalski wrote:

> I seem to remember that the special thing about Perl was that we 
> misclassifed an
> interface too highly.  This has been corrected.  Hence Perl was a 
> special case to
> allow fallback because we misled about the stability of (I think) the 
> plug-in interface.
> I'm hazy about this which is why I haven't said too much until I get a 
> chance
> to re-examine the Perl case.  I think everyone else should also stop 
> talking about
> the Perl precedent until they re-examine the case to see why this was 
> allowed.

For the purposes of discussion perl can be thought of as having 2 
interfaces, one is the 'script-level' interface and the other is the 
'C-level' or more correctly the 'XSUB-level'.  Perl-only modules on CPAN 
consume the first interface, modules with a C component consume the second.

The perl-level interface is stable and backwards-compatible across releases.

The XSUB-level interface consists of a series of C functions and macros, 
the implementation of which may change between releases (although the 
code-level interface is stable).  Although a XSUB module compiled 
against a previous version of perl *may* work with the next version, it 
isn't guaranteed, and it is safest to recompile any such modules against 
the later version.

At present, the only packages we deliver, and that therefore other 
things which require perl can express packaging dependencies on are 
these packages:

SUNWpl5m                           Perl 5.6.1 Reference Manual Pages
SUNWpl5p                           Perl 5.6.1 (POD Documentation)
SUNWpl5u                           Perl 5.6.1 (core)
SUNWpl5v                           Perl 5.6.1 (non-core)
SUNWperl584core                    Perl 5.8.4 (core)
SUNWperl584man                     Perl 5.8.4 Reference Manual Pages
SUNWperl584usr                     Perl 5.8.4 (non-core)

Before we got long package names we had to do a horrid packaging dance 
(is there any other kind?) each time we upgraded - the existing packages 
were renamed from SUNWpl* to SUNWopl5, and the new packages were given 
the SUNWpl* names.

Currently, if a package needs perl it has to express a dependency on 
SUNWperl584core and SUNWperl584usr.  However, that ties it to a specific 
version of perl.  That's what is required for packages that consume the 
perl XSUB-level interface, but it means that packages which only use the 
perl script-level interface are unnecessarily bound to a specific 
version of perl, when any later-but-compatible version would be fine.

Bugid 6309711 "Perl should deliver a stable package for dependents to 
depend on" addresses this issue.  The intention is to provide a new 
package, SUNWperl5 which will just contain the symlinks under /usr that 
point to the latest version of perl.  Packages which consume the perl 
script-only interface can express a dependency on SUNWperl5 and will 
therefore be unaffected by perl version upgrades.  Packages which 
consume the XSUB interface will still be dependent on the 
version-specific packages as before.

-- 
Alan Burlison
--

Reply via email to