Re: Debian Perl Group meeting at DebCamp - 2008-08-06
> -=| Jeremiah C. Foster, Sat, Sep 06, 2008 at 12:26:59PM +0200 |=-
> > > On Wed, 06 Aug 2008 18:01:21 -0300, gregor herrmann wrote:
> > 1. Perl hackers would get tools to build debs that are built by
> > people who follow debian perl policy automatically increasing their
> > quality.
>
> I thnk you overestimate the work done by dh-make-perl a bit :)
Maybe, but I would like to use parts of its functionality sometimes,
without having to dig around and see the various bits.
> Yes, it does a lot of boring work automaticaly, and this is very good
> thing, no doubt. However, I often find out that the real work starts
> just after dh-make-perl has created the skeleton - license checks,
> build problems, Policy compliance, etc, etc
In my limited experience, this has been true for me as well. The real
work starts once dh-make-perl has created a skeleton.
> Even if I don't understand the benefit of havinng all CPAN mass-built
> as .debs, it seems people want that and if they find dh-make-perl
> useful for this, be our guests :)
I have come to feel that CPAN automatically transformed into debs is
probably impossible. It is not my goal at all, and I think I can show
why automated deb building using the various _existing_ tools is
bad. But to do that I need to do some more testing.
>
> > 3. Documentation would have to be improved by default because of
> > increased public consumption. (Or that is the hope anyway. :) )
> >
> > Can we move some of the dh-make-perl stuff to CPAN? I am willing to
> > do the work, or at least some of it.
>
> I am not sure I fully understand what you mean. I am used to think of
> CPAN as a place where 'upstream authors' work. And as I prefer to have
> the group as 'upstream' for dh-make-perl, I am confused.
Well I would like to get the versions of a long list of perl
modules. That list is the Phalanx 100. I then build debian package
names out of that list with some data munging and finally call
`aptitude show libfoo-perl` and grep the version number. Then I compare this
to what exists on debian.pkgs.cpan.org to see which package is older.
I realized that Tincho does this already and thought that I could
save a lot of time just using the code in qareport.cgi.
But that tool uses some DebianQA modules that are somewhere - just
not on CPAN. So I have to dig around alioth I suppose (which is not a
bad thing really, just less than ideal) to find them as opposed to
just getting them from CPAN.
There is a lot of debian-centric stuff on CPAN already, just not
built by the people who understand and care about debian policy. But
I understand what you mean by pkg-perl serving as the best repository
for these tools, its just sometimes they are hard to find.
> > I have been thinking about writing some documentation regarding
> > this, especially after reading emails sent by ntyni (as well as dam,
> > gregoa, gwolf, djpig, et. al.) and being amazed at their ability to
> > locate the source of what appear to me to be really complex
> > problems. Would you guys be willing to have me "interview" you
> > via email regarding the triage process so I can create
> > a more "entry-level" document for those of us who do not have your
> > gifts?
>
> That would be interesting to have.
I'll get started writing that.
Jeremiah
Reply to: