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

Re: List of modules I need



Hi,

[ Switching to debian-perl@l.d.o.  pkg-perl-maintainers is mostly used ]
[ for bug mails and other discussions easily get lost here.            ]

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?

[ 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>

> 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.

> 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?

>>>  * 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>

>> 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.

Regards,
Ansgar


Reply to: