Re: Utility to install a perl module via apt with cpan fallback
I think we've got a lot of the same thoughts here.
On Sat, Jan 10, 2009 at 7:01 PM, Jeremiah Foster
<jeremiah@jeremiahfoster.com> wrote:
>
> On Jan 11, 2009, at 12:16 AM, Jonathan Yu wrote:
>
>> Jeremiah:
>>
>> I think the intent of this one isn't to create the perl .deb package;
>> it's simply to select the appropriate .deb package if it already
>> exists in the mirrors, and simply fall back (as in the subject) to
>> CPAN-style installation.
>
> Definitely, I am not disputing that. :) But the end result is the same or
> roughly similar don't you feel? Or a step in that direction.
>>
>> This is more for users than prospective developers.
>
>> But I think it perhaps warrants some work to make a machine that would
>> fetch CPAN modules and try to run dh-make-perl to construct .deb
>> packages from them. We could perhaps pick the top rated modules and
>> try to turn those into packages; for the ones that fail, it would flag
>> which ones might be more difficult to do.
>>
>> Just some thinking out loud.
>
> Good thinking! :)
>
> This is something that I am working on as well;
> http://www.jeremiahfoster.com/debian/phalanx100-debian.html
>
> What I have started to do is look at the feasibility of automated package
> creation, only because I think it is inevitable and if it is to be done it
> should be done right by people who understand debian. (I'm not saying that I
Indeed. I personally don't understand Debian all that well, but I
think now that dh-make-perl has become its own module, this should be
easier.
> am the right person for the job, just that I'm fooling around trying to get
> some info.) There already is a mechanism to create packages with CPANPLUS
> and I think there are some problems with the resulting packages that should
> be addressed. I think automated package creation is asking for trouble, but
> as I mentioned, it feels inevitable.
Perhaps. I think, though, we can create a tool that will try to
convert CPAN modules into deb packages fro users, sort of like
dh-make-perl, but with a CPANPLUS-like ability to report
installation/bug reports to a central bug database of sorts.
>
> As far as the top-rated modules go, I think testing those is a really good
> idea. Using those and maybe the phalanx 100, which is actually more than
> 100, perl modules that perl considers a representative group of modules.
> Creating an intermediate step between CPAN and debian where we can run some
> automated tests on debs, modules, or potential packages, might also be a
> useful place to spot bugs both in packages and in perl which might be a
> service to both groups.
>
> I can imagine, for example, a mini-cpan on an alioth-like machine. That
> mini-cpan (all of the latest versions of CPAN) would get turned into debs
> automatically, built in a cowbuilder, tested with linitan, and have some
> additional testing framework that might be part of CPANTS and/or a debian
> specific test suite. This partially debianized CPAN might be the place where
> debian packagers go first to get a more reliable module from CPAN and
> quickly get it into debian if it meets human quality standards.
>
> Even if this process does not make perfect debian packages, and I doubt it
> ever could, and if it did, we need to impose human intervention somehow, it
Similarly, though, the human process can't make perfect Debian
packages unless everyone is well-versed in Debian. So this sort of
lowers the barriers to creating packages, and I'd argue that with
automated kwalitee-like test metrics on our side, we can hammer out
the more obvious problems. And with more testing under different
platforms, we can make sure stuff works under other platforms.
The CPAN testing service, while it doesn't replace code review, has
been really useful for module developers like me - particularly when I
was starting out. It tells you what to watch out for, and modules like
Perl::Critic that analyze code ensure that stuff matches the "best
practices" determined by the experts.
As the pkg-perl team's responsibilities increase with more and more
modules, it's unlikely that we'll also have corresponding growth in
the genius packagers of the likes of gregoa and dam, et al. So, I
think it's in the community's best interests to do what we can to make
their lives easier, and automatic building and testing is part of
that.
We're not totally removing the idea of review from the entire process,
I just think creating more packages faster would be nice.
Perhaps another idea is a "package queue", which would be a listing of
CPAN packages that people want Debianized. Then we could allow people
(perhaps only those with Alioth or Bitcard accounts) to "vote" up the
module, basically indicating that people want the module. So we can
tackle the modules with the highest votes first, and try to build them
automatically. Then the expert packagers could take a look at them.
> will still be an excellent "testing ground" for both modules and debs. Perl
> has always had an excellent reputation for testing and debian has an
> excellent reputation for quality assurance, perhaps we could create a tool
> or framework that would use the strength of both these ecosystems to provide
> both easier system administration, higher quality modules, and fewer perl
> bugs.
>
> Jeremiah
>
>
> --
> To UNSUBSCRIBE, email to debian-perl-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
>
I think all of this warrants lots more thought. Perhaps we should whip
up a basic Wiki page on our ideas here, and see what happens?
Cheers!
Reply to: