Re: List of modules I need
> Richard Holland <holland@eaglegenomics.com> writes:
>
> You said you have no experience building "Debian modules". Do you mean
> Debian packages in general or Debian packages for Perl modules?
>
Both. Never done either.
> [ libwww-perl v5.808 ]
>>
>> 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.
>
> Introducing old, unmaintained versions of something is in general not a
> good idea. Moreover you would have to rename all included Perl modules
> as they conflict with the files from the current libwww-perl (which
> quite a lot of other packages depend on).
>
> I am pretty sure the security team would also not be happy about this.
>
> It is also not possible to just add a package "libwww-perl-5.808" as it
> would not be co-installable with libwww-perl (both contain the same
> files). You would have to rename all shipped Perl modules and change
> this in depending packages as well.
>
> Is the Ensmbl you are talking about this one: [1]? I did take a short
> glance at the page and they also depend on an old version of BioPerl[2]:
> 1.2.3, Debian has 1.6.1 right now, even stable has 1.5.2...
>
> [1] <http://uswest.ensembl.org/index.html>
> [2] <http://uswest.ensembl.org/info/docs/api/api_cvs.html>
>
Yes that's the exact same Ensembl that I'm trying to Debianise. BioPerl is integrated into the Ensembl install directory, not installed externally via CPAN, so it wouldn't be installed as a separate package.
>> 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?
>
> All dependencies of packages in the Debian archive must be satisfied
> with packages from the same place so this is not an option.
OK, so seeing as 5.808 can't itself be in Debian, yet to depend on it it must be in Debian, somehow instead I must do something that looks like 5.808 to Ensembl only - see below.
>
>> How does Debian deal with other situations where Debian package A
>> depends on package B <= version X rather than >= version X?
>
> In this situation one of the two packages needs to be fixed. Personally
> I don't think we should introduce packages that do not work with current
> versions of software from Debian.
>
>>>> New modules:
>>>> * Math::Bezier
>>>> (no dependencies)
>>>> * RTF::Writer
>>>> (depends on libimage-size-perl)
>
> These look unproblematic.
>
>>>> * LWP::Parallel::UserAgent
>>>> (depends on the special case above)
>
> Is this the only reason why you need the old version of libwww-perl or
> are there other incompatibilities?
I believe this is the main reason. LWP:: Parallel:::UserAgent is used extensively throughout Ensembl code. (Did some double-checking and apparently libwww-perl 5.812 will also work, but its still very old and also not in Debian).
Would it work if I simply packaged LWP::Parallel::UserAgent and the dependent version of libwww-perl into the Ensembl .deb, in a subdirectory of the Ensembl install location (clearly distinguishing the licences and sources of course, and naturally checking the licences of both first to see if this is permissible). This is the same way that BioPerl gets integrated. That way the old code could stay inside the Ensembl install location and only be used by Ensembl itself, as it would be configured to use its own Perl modules, where present, in preference to system ones.
Or are there drop-in alternatives to LWP::Parallel::UserAgent in Debian that I could use instead? (without having to modify any Ensembl code.)
>
>>>> * Bio::Das::Lite
>>>> (depends on libio-stringy-perl, libwww-curl-perl,
>>>> libreadonly-perl, and the special case above)
>
> Does this really require the old libwww-perl? There are reports [1] on
> cpantesters where the test suite passes with libwww-perl_5.836.
>
> [1] <http://www.cpantesters.org/cpan/report/07507005-b19f-3f77-b713-d32bba55d77f>
>
I will trust the report! So it should be an 'easy' one without that special case dependency required.
>>> 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.
>
> As you already joined pkg-perl on Alioth, I assume you want to package
> the modules yourself? In that case you want to file an "ITP" (intend to
> package) rather than a "RFP". You might want to start with Math::Bezier
> and/or RTF::Writer. Both look good to start learning packaging with.
>
I filed RFPs first in case anyone picked them up (I won't start working on this in earnest until next week), then as/when I start to try and package the 'easy' ones (Math::Bezier and RTF::Writer and Bio::Das::Lite) I'll do ITPs on the existing RFPs - unless someone else grabs them first.
cheers,
Richard
> Regards,
> Ansgar
>
>
> --
> To UNSUBSCRIBE, email to debian-perl-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: 87d3tqnwjg.fsf@marvin.43-1.org">http://lists.debian.org/87d3tqnwjg.fsf@marvin.43-1.org
>
--
Richard Holland, BSc MBCS
Operations and Delivery Director, Eagle Genomics Ltd
T: +44 (0)1223 654481 ext 3 | E: holland@eaglegenomics.com
http://www.eaglegenomics.com/
Reply to: