List of modules I need

[Nicholas Bamber]

I'd be happy to do the packaging work of the forked package so long as:

* The package wherever possible is done according to the normal 
processes of the Debian perl group;
* There is an RFP as discussed (I like the satisfying feel of a 
'--closes' argument when you run dh-make-perl).

A few other implications I can think of:

* In the control file there must be a "conflicts with liblwww-perl" clause
* There must be a README.Debian documenting why the package was created 
and warning that it should not be used for normal purposes.

Nicholas

Richard Holland wrote:
> Thanks David.
>   
>> Don't be too discouraged if response is a bit slow. The perl group is
>> mainly focussed on fixing bugs now that squeeze has been frozen.
>>     
>
> That's fine. I'm quite happy to build them myself locally for now to learn how it all works, and then either submit or wait for 'official' versions later.
>
>   
>> [snip]
>>     
>>> Here's the modules I need:
>>>
>>> Special cases:
>>>       
>>>  * libwww-perl - must be able to install version 5.808 exactly as
>>>  other parts of my project (stupidly, but beyond my control) depend
>>>  on features in 5.808 that were removed in later versions. 
>>>       
>> There can only be one version of a given package in a given suite, so
>> when these kind of things are necessary, the package needs to be forked,
>> and given a new name. Given how 5.808 package is, and the fact that the
>> package is security sensitive, my personal reaction to having a two year
>> old version in the archive is not too enthusiastic. In any case, if we
>> are going to fork the package, someone needs to take responsibility as
>> the new upstream maintainer (i.e. to deal with non-packaging
>> issues). Are you able to do that?
>>     
>
> The problem with this Perl package is that the original version is no longer maintained, but the team that produces the code I'm using (Ensembl) depends on it in a number of complex ways and is not planning to remove the dependency any time soon - even though the equivalent CPAN module is no longer available on all except a couple of mirrors. 
>
> I wouldn't want to maintain the Debian package if it was forked because the content/function of that particular package is outside my expertise.
>
> What would you recommend as an alternative approach that would be Debian-safe - given that I can't remove the dependency on the original CPAN module? Just to keep the existing debian-cpan version as a dependency and state that users of my Ensembl package will need to add that repository before they can install it?
>
> How does Debian deal with other situations where Debian package A depends on package B <= version X rather than >= version X?
>
>   
>>> New modules:
>>>  * Math::Bezier
>>>    (no dependencies)
>>>  * LWP::Parallel::UserAgent
>>>    (depends on the special case above)
>>>  * RTF::Writer
>>>    (depends on libimage-size-perl)
>>>  * Bio::Das::Lite
>>>    (depends on libio-stringy-perl, libwww-curl-perl, libreadonly-perl, and the special case above)
>>>       
>> Normally just sending email as you did would be perfect and someone
>> would jump right on it. However, as I mentioned above, most team members
>> are concentrating on getting the next Debian Stable release out the door
>> right now. In order that your request not get lost, the best thing might
>> be to file RFP (request for package) bugs by using "reportbug wnpp" and
>> following the prompts.
>>     
>
> Thanks. I'll do that. 
>
> cheers,
> Richard
>
>   
>> All the best,
>>
>> David Bremner
>>     
>
> --
> Richard Holland, BSc MBCS
> Operations and Delivery Director, Eagle Genomics Ltd
> T: +44 (0)1223 654481 ext 3 | E: holland at eaglegenomics.com
> http://www.eaglegenomics.com/
>
>
> _______________________________________________
> pkg-perl-maintainers mailing list
> pkg-perl-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-perl-maintainers
>
>