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

Re: Perl packages, CPAN, locally installed .pm files



Manoj Srivastava <srivasta@datasync.com> wrote:
>         I had not considered modifying ExtUtils, firstly, because I
>  didn't think I could get a patch in (it would be presumtuous of me to
>  think otherwise, don't you think?), and secondly, it is not
>  necessary.

Hmm... make-ppkg looks like an excellent concept, but I was 
envisioning something which would work from within the CPAN user
interface (perl -MCPAN -e shell).

>         Specifically, the Debian control file information; which
>  has things like which section (devel/libs/net/x11 etc), whether it
>  is meant for the stable or the development Debian tree, whether it
>  is part of the main distribution, or it is contrib or non-free,
>  description, dependencies on toher debian packages, debian-revision,
>  and a package name that meets debian Policy.

For the case of CPAN, you can fix the section (cpan), and put it in
the development tree till it's been certified stable.  If any cpan
packages can be non-free, you could make the default be non-free.

I don't buy the idea that good package descriptions are only needed
by debian.  I think we could talk the CPAN maintainers into a
"description intended for browsing" concept, though we might have to
flesh out how it would work in their UI.

Finally, I wasn't aware that there were any problems with cpan
names or version numbers.  I don't think that non-alphanumeric
characters are going to be all that significant, except as delimiters,
so it shouldn't be hard to mechanically apply some sanity-rules.

>         What I'm trying to say is that a Debian package requires
>  information that is Debian specific, and it seems unfair to ask
>  authors to include it in the package (even if they were conversant
>  with Debian policy).

This works for important packages.  If it works well enough, we
wouldn't need to hack up perl's cpan interface.  However, it
doesn't make cpan browseable -- so either we'll need a reasonably
up-to-date mirrored archive of cpan, or we'll need some way for
debian users to browse cpan looking for candidate packages.

[Of course, once we have adopted the best version of all the important
packages, browsing won't be an issue. But I suspect that will only
happen when active perl development drifts away from cpan.]

-- 
Raul


--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: