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.
Right, i've added the Replaces: header as suggested by schwern. It does work, butThere 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.
perhaps it's a bit to vigorous;
[EMAIL PROTECTED] ~...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: [EMAIL PROTECTED]
Description: Executes perl-style tests
[EMAIL PROTECTED] ~...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.
Right, we will have to take our chances then. As described below, we can* 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.
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
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
