Re: [Cpanplus-devel] Re: Advice requested; Automatic building of debian packages from CPAN modules
On Dec 7, 2004, at 3:30 PM, Brendan O'Dea wrote:
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.
This is good news, and already the way it was being done.
So that's all taken care of.
A few notes on the documentation though:
[http://www.debian.org/doc/packaging-manuals/perl-policy/ch-
module_packages.html]
Module packages must install manual pages into the standard directories
(see Documentation, Section 2.4) using the extensions .1p and .3pm to
ensure that no conflict arises where a packaged module duplicates a
core
module.
s/.1p/.1pm/ surely.. not sure how you'd like a patch against the
webdocs :)
4.2 Module Package Names
Perl module packages should be named for the primary module provided.
The
naming convention for module Foo::Bar is libfoo-bar-perl. Packages
which
include multiple modules may additionally include provides for those
modules
using the same convention.
Hmm, not all debian provided packages follow this naming scheme. Most
notably the
cpan package 'libwww-perl' doesn't end up as 'liblib-www-perl-perl' (as
cpanplus
makes it now) but as plain 'libwww-perl'. Is there any way to predict
this naming,
so we can have consistent naming from both debian + cpanplus?
Thanks for clearing this up though, it's a very concise summary, and a
very good reference point.
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.
Right, i've added the Replaces: header as suggested by schwern. It does
work, but
perhaps it's a bit to vigorous;
[kane@omen ~...dist/debian]$ dpkg --info
libtest-harness-perl_2.44-1_all.deb
new debian package, version 2.0.
size 45392 bytes: control archive= 691 bytes.
286 bytes, 10 lines control
722 bytes, 10 lines md5sums
Package: libtest-harness-perl
Version: 2.44-1
Section: perl
Priority: optional
Architecture: all
Depends: perl (>= 5.6.0-16), libpathtools-perl (>= 3.01)
Replaces: perl-modules, perl-base, perl
Installed-Size: 148
Maintainer: cpanplus@example.com
Description: Executes perl-style tests
[kane@omen ~...dist/debian]$ sudo dpkg -i
libtest-harness-perl_2.44-1_all.deb
Selecting previously deselected package libtest-harness-perl.
(Reading database ... 53946 files and directories currently
installed.)
Unpacking libtest-harness-perl (from
libtest-harness-perl_2.44-1_all.deb) ...
Replacing files in old package perl ...
Setting up libtest-harness-perl (2.44-1) ...
This is just to update '/usr/bin/prove'.
Now, does 'Replaces:' also affect the /other/ files in this package
that overlap in
name (but not location, as you've explained) from the
perl-base/perl-modules package?
And what happens if a user now tries to install a new version provided
by debian of
perl-modules, perl-base? will it happily install again, or will it now
also have to
specify a 'Replaces:' to get back 'its' /usr/bin/prove?
The same question of course goes for 'what if it's older version' 'what
if it is
deleted from the core', etc... they're edge cases, i'm aware, but i'm
curious none
theless.
* 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.
Right, we will have to take our chances then. As described below, we can
only really make assumptions about the perl we are currently running,
and
not what would work for a different version of perl. Again, these are
edgecases i think.
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.
Possibly... I'll leave this one as a 'Possible TODO' for now, if we find
conflicts arise (or if you can already predict them).
* 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.
Both actually... Obviously people should be able to install cpan modules
via their own package manager, and have that Just Work. But also, we
(cpan.org) would like to offer a place to grab bleading edge debian
packages
of what's current on CPAN for those who want them. This could be the
official
debian maintainers (inspect the package, possibly tweak, submit to the
debian
pool), or people who'd rather have things prebuilt for them.
I'm not sure what's wise here.. currently we don't put in a Depends for
any
perl version.
--
Jos Boumans
"If superman is so smart, why does he wear underpants over his
trousers?"
CPANPLUS http://cpanplus.sf.net
Reply to: