I believe this package is already done and sitting in our repository... It's under "Tagged but not in the archive yet" which means it's heading out to the archive at large.
However, I think within the Perl community, this is something that is already widely understood -- that is, dual-lived modules. As an example, this is what apt-cache shows me for libmodule-build-perl (which is part of perl-modules 5.10 and up): Package: libmodule-build-perl Priority: optional Section: perl Installed-Size: 680 Maintainer: Debian Perl Group <pkg-perl-maintain...@lists.alioth.debian.org> Architecture: all Version: 0.3300-1 Depends: perl (>= 5.6.0-16), libarchive-tar-perl, libyaml-perl, libextutils-parsexs-perl Recommends: libextutils-cbuilder-perl, libversion-perl, libpod-readme-perl Suggests: libpar-dist-perl (>= 0.17) Filename: pool/main/libm/libmodule-build-perl/libmodule-build-perl_0.3300-1_all.deb Size: 259330 MD5sum: a4d8e1f1b9fa09e66f6e3f7c9c0174d9 SHA1: d7bac6e297e4b66e517a79c4df7f7a6644134a97 SHA256: 9b68211cb027f3054fa028440311cd2f5c0285cce113af52b19077929e096649 Description: Subclassable and make-independent perl module builder alternative Module::Build is a system for building, testing, and installing Perl modules. It is meant to be a replacement for ExtUtils::MakeMaker. Developers may alter the behavior of the module through subclassing in a much more straightforward way than with MakeMaker. Homepage: http://search.cpan.org/dist/Module-Build/ Tag: devel::lang:perl, implemented-in::perl, role::shared-lib There is absolutely no mention of this being a dual-lived module. However, anything that goes through the pkg-perl group is first checked by our main sponsor, gregoa. And he always makes sure we do something like: Build-Depends: perl-modules (>= 5.10) | libmodule-build-perl (Assuming both can be used. On the other hand, libmodule-build-perl is only 0.28 or so in the perl-modules core package; if a newer version is necessary then that version will need to be depended upon, as mentioned). Anyway, this is the good thing about having a team that can manage Perl packages (or any similar set of packages) to review them all and make sure they meet some sort of standard. It's more difficult to do this on the wider Debian archive with various people contributing things and various other people (many of whom do not have much experience with packaging Perl) reviewing things. This is particularly why I'd encourage people to consider packaging something under the umbrella of pkg-perl. All in all, I think this package is useful even if there is no real difference between the core package and this one. Why? The same reason we say to prefer EITHER perl-modules >= 5.10 OR libmodule-build-perl. We can install on a system (say oldstable) that does not have Perl 5.10 installed; however, it might be able to trivially backport libmodule-build-perl. All with the added advantage of being able to keep a newer version of libmodule-build-perl up to date, which might come out of sync with the core version (and is likely to do so over the life cycle of the Perl release). I can definitely see why there might not be merit to uploading it if there are no changes as compared to the current version. We obviously don't want something made totally unnecessary by the Perl core modules to pollute the Debian archives. Still, I think the benefits outweigh the downsides of such an arrangement. Niko's suggestion of using a description to alert users and other maintainers about the purpose for such a module is great, and I have no objection to that. Perhaps this is something we can consider in a broader sense to help our users decide. We have to keep in mind though that newer releases of perl-modules may mean that we'd have to remove that particular section, and isn't this essentially what debian/changelog is supposed to be for? Another question is.. If there is a bug with Module::Build that we need to fix, should a bug be filed against perl-modules (>= 5.10) or under libmodule-build-perl? We could upgrade our own version and apply our own patches, and just require that in B-D for modules where a bug in M::B is problematic. It's more difficult to get it fixed in perl-modules and subsequently require perl-modules (>= 5.10-11) or what-have-you. Cheers, Jonathan On Tue, May 26, 2009 at 9:59 AM, Niko Tyni <nt...@debian.org> wrote: > On Tue, May 26, 2009 at 09:41:53AM -0300, Brian Cassidy wrote: >> On Tue, May 26, 2009 at 9:24 AM, Steve Kemp <s...@debian.org> wrote: >> > This module is already packaged: >> > >> > sh-3.2$ ls /usr/share/perl/5.10.0/File/Temp.pm >> > /usr/share/perl/5.10.0/File/Temp.pm >> > >> > sh-3.2$ dpkg --search /usr/share/perl/5.10.0/File/Temp.pm >> > perl-modules: /usr/share/perl/5.10.0/File/Temp.pm >> > >> > Did you miss this, or is it being removed from perl-modules? >> >> File::Temp is dual-lived (Core+CPAN). This package is meant for users >> and other packages that require more >> recent versions of the module that get shipped to CPAN. > > Please mention this in the package description. For instance, > this is what I put in podlators-perl: > > Note that the Perl core distribution (supplied in the perl package) > already includes older versions of these modules and scripts. Please > depend on this package only if you specifically need the newer > features, for instance the improved UTF-8 support. > > Also see #497130, which led to the removal of the previous incarnation > of libfile-temp-perl (at version 0.20). > -- > Niko Tyni nt...@debian.org > > > -- > To UNSUBSCRIBE, email to debian-perl-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
