Re: Advice requested; Automatic building of debian packages from CPAN modules
On Tue, Dec 07, 2004 at 10:18:12AM +0100, Jos I. Boumans wrote:
>While building these .debs we've got very encouraging results, and barring
>debian policy option tweaks, they're 'technically' sound. However, one issue
>arises: The debian package system does not allow a file to be 'owned' (or
>provided) by 2 different packages, which is a problem when updating core modules
>from CPAN (like for example Test::More and Cwd):
>
> dpkg: error processing libtest-harness-perl_2.42-1_all.deb (--install):
> trying to overwrite `/usr/bin/prove', which is also in package perl
> Errors were encountered while processing:
> libtest-harness-perl_2.42-1_all.deb
>
>Now, in 'perl land' it's quite common to have a file be able to come from 2
>different sources (like perl-core and CPAN), so the question is: what does
>debian do here?
You should probably take a look at the Debian Perl Policy document:
http://www.debian.org/doc/packaging-manuals/perl-policy/
Section 3 deals with locally installed perl modules, and section 4 on
packaged modules.
In short, the @INC order is setup to prefer modules installed with
INSTALLDIRS=site, then =vendor, the the packaged perl.
On Debian systems, members of the "staff" group have write permission on
/usr/local, so if an administrator wishes to install a newer version of
a CPAN module, building and installing that module with INSTALLDIRS=site
will work.
Alternately, newer versions of modules may be built into packages which
use the vendor directories.
Due to the fact that core and vendor modules use different paths for
module installation and different suffixes for manual pages, there is
not typically a problem with duplicate files.
There is however an overlap of the vendor and CORE bin/script directory
which can cause a problem like the one you've reported above.
Locally installed modules use /usr/local/bin, so don't have this
problem.
It is only an issue for a small number of modules which are both in CORE
and also install scripts. These cases may be solved by the maintainer
by adding an appropriate Replaces header.
>It seems that debian, when a core modules is updated on CPAN, prefers to update
>it's own 'core' perl package to include the updated CPAN module. Thus
>effectively generating a say, '5.8.4-2', which is the same as the original perl
>5.8.4 release, with the updated CPAN module in it.
Not generally. Changes in the Debian version (the -N suffix) indicate
changes in the packaging (dependencies etc.) and bug fixes, which for
the most part are back-ported from maint.
Such fixes do occasionally include a complete update of a CPAN module
which is part of core, but this is incidental to the fix rather than the
motivation.
See:
http://packages.debian.org/changelogs/pool/main/p/perl/perl_5.8.4-4/changelog
Note: the NMU (non-maintainer upload) of 5.8.4-2.3 which updates
MIME::Base64 is atypical.
>So far, all well and good, but this creates problems when automatically
>generating packages that are, or depend on, modules that are dual-lifed (ie
>exist on CPAN and in the core), as we can not 'just' install the CPAN module
>on top of what the (debian) core already provided. I can think of a few
>possible scenarios:
As described above, outside of the issue with /usr/bin, in general you
can just install a package of a CPAN module on top of what the core
already provides.
> * The most recent version of the CPAN module has not been integrated
> into the debian perl core. Any module that has a requirement on this
> more recent version will now have unmet dependencies.
There is some attempt to deal with such dependencies, but generally in
the other direction: if a CPAN module (say "Foo"), was previously
packaged independently becomes part of core in a subsequent perl
release, then the new perl (or perl-modules) package will Provide and
Replace "libfoo-perl", and conflict with "libfoo-perl (<< V-1)" where V
is the version of the module which is now part of core.
The intent is to allow anything which depended on "libfoo-perl" to work
with the newer version provided by the core perl packages, while
allowing an independent package of the same or newer version to be
updated.
This process is manual, and since the addition of such C/R/P headers is
done only when a new module is added to core, the current list is not
(nor is it intended to be) a comprehensive list of the modules in core.
Additionally, since dpkg doesn't support versioned Provides, this only
works for packages which depend just on "libfoo-perl", rather than a
specific version of that package.
The only way around this issue is for packages with requirements on a
specific version to depend on "libfoo-perl (>= V)" when the module is
not in core, to change that dependency to "perl (>= X)" if perl version X
includes a version of the "Foo" module greater than V.
It may be possible for you to apply the above programatically, by
interpreting the Provides/Conflicts of perl and perl-modules to
determine if a dependency on libfoo-perl or perl is required.
> * As I only know the environment of my current perl that I am building
> this debian package with (core perl module versions vs CPAN versions
> vs build requirement), I can only guarantee that the package I am
> about to create will work with the version of perl I am currently
> building it with. That effectively means requiring everyone to
> upgrade to at least this version of perl in order to use the
> package. From a 'perl' point of view, there's absolutely no need
> for this, but it might be required for debian.
> Ideally of course, we want the package to depend on the version
> of perl it says it needs, rather than the version of perl it was
> built with.
I'm not quite clear on the intent here. If you're attempting to provide
an easy way by which administrators may create local packages for
distribution across a group of machines, then a dependency on the build
version of perl (including the Debian revision) is probably fine (since
running "apt-get upgrade" from a local repository will likely upgrade
perl to that version anyway).
Alternately, if creating packages for upload to the main archive is your
goal, then the maintainer should be applying some discretion to the
resulting source package.
--bod
Reply to: