Re: Documentation: "How to get a CPAN module into debian"
On Sun, Aug 3, 2008 at 11:12 PM, Damyan Ivanov <email@example.com> wrote:
> -=| Jeremiah C. Foster, Sun, Aug 03, 2008 at 06:13:05PM +0200 |=-
>> I am giving a talk for YAPC::EU about debian from a perl developer's
Can you please also update the wiki page where the Perl community maintains
a global set of suggestions ?
>> One of the things I wanted to talk about and that I
>> occaisionally get asked is "How do I get module X into debian?"
> Hopefully, Debian users know how to propose new packages.
Don't assume that, please.
> Also, "write clean copyright and licensing statements".
We have been in this discussion already. The above request is
too vague. I don't understand what that means to you.
Jim Brandt from TPF promised me on YAPC::NA to check how
and where one should declare "the same license as perl"
to make it strong enough to be defendable.
I am expecting an exact phrasing of the sentence or sentences.
Once we get that you too will be able to point CPAN authors
to that statement and I hope we can add this check to CPANTS.
> I would object, however, against RFPs filed by module authors that
> seek popularity for their module. Let them distribute their work in
> CPAN, accumulate users, and let the /users/ file RFPs in case they
> also happen to use Debian. Otherwise we may as well blindly mirror the
> whole CPAN :)
> How about changing the title to "How to get the CPAN module I use in
There is a chicken and egg problem here.
In short: because many modules are missing people use alternative ways
and then don't ask for modules to be included. So you don't see the requests.
As I explained to some of the people (including Jeremiah) there is a
problem here. While you guys hope that your users will only use .deb
packages and hope that your users know how to request modules
being added to Debian in reality IMHO things work slightly differently:
1) most of the corporate users have no clue or willingness to talk to you
(nor to anyone in the "community")
they are in the corporate mindset where
"who are we to ask our great and majestic vendor to do something for us"
2) It won't really help them in the short term as they use Debian stable and
the modules will only get added much later further reducing their
willingness to ask for it. They need things to be solved NOW.
3) There are tons of important modules still missing from Debian so users
have to use other methods for installing them.
In addition the Perl community recommends CPAN.pm/CPANPLUS as the
method (partially because there are modules missing in stable)
With alternative solutions in place and low level of willingness to
participate in the
community from some of the users bring us to low level of requests to add more
I think it might be a good idea to create a rule what modules Debian
includes even without
specific requests. Eg:
"Any module that is a prereq by another module from another author."
(ok, maybe you can skip the Acme:: namespace and apply some judgement)
Another rule would be
"Most of the modules that require external C libraries"
"Most of the modules that require C compiler"
These are the module that are more difficult to install and require better
integration with the OS than a module with just Perl code.
> Considering the above, I think that the 'reportbug way' should be the
> only variant explained. I'd add a hint how to search the wnpp list for
> the proposed package using its ability to filter the bug list.
> Also, a Link to the PTS would be good, also to the Perl sub-policy.
> Last note. If you happen to meet Jesse Vincent, please ask him to add
> a proper License statement to Template-Declare. Right now the module
> only has COPYRIGHT and the only mention of license is "License: perl"
> in META.yaml, which is a bit scarse. :)
AFAIK in recent versions of META.yml there are links to a web site with the
full text of the "perl" (and some other) licenses.