Re: Bug#530615: ITP: libfile-temp-perl -- return name and handle of a temporary file safely
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-maintainers@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 <ntyni@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 <skx@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 ntyni@debian.org
>
>
> --
> To UNSUBSCRIBE, email to debian-perl-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
Reply to: