[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#530615: ITP: libfile-temp-perl -- return name and handle of a temporary file safely



Oh, another note:

In this case, yes, File::Temp has changed a lot. (See:
http://search.cpan.org/diff?from=File-Temp-0.18&to=File-Temp-0.21)

However, a lot of the changes are bug fixes and small feature
additions, which I think are difficult to mention in a description. A
more appropriate place might be debian/changelog, as a sublist under
the New upstream release point. But really, I don't think upstream
changelog really belongs there - if the user wants to check what has
happened between 0.18 and 0.21, they can check the changelog or the
diff (see above) themselves.

Let's say a CPAN module author has written something which uses
File::Temp, but that knows it depends on a bug fix (this happens often
in practice). Then they'd just depend on the new File::Temp version,
which is no longer core, and it'd need to be packaged.

I think that given the large number of bug fixes, the new package
makes sense. Otherwise, the other option is to apply a horrendous set
of patches to perl-modules for little gain, since modules really
depending on the fixes that have been made can depend on them
explicitly (and if they are broken, this is something likely to cause
test failures which we will notice when building via pbuilder and
correct. Or the module author will notice the CPAN Test reports and
fix it themselves).

Cheers,

Jonathan

On Tue, May 26, 2009 at 11:05 AM, Jonathan Yu <jonathan.i.yu@gmail.com> wrote:
> 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: