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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
