public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] Re: perl extra modules
       [not found]           ` <20020708120342.GA2576@ns0>
@ 2002-07-08 12:27             ` Michael Cummings
  2002-07-08 15:41               ` Leon Brocard
  0 siblings, 1 reply; 5+ messages in thread
From: Michael Cummings @ 2002-07-08 12:27 UTC (permalink / raw
  To: gentoo-dev; +Cc: gentoo-user

Leon,

	Agreed this should be over on dev (cc'd -user just so the thread
watchers know).
	OK, so after sending that last message, I began thinking it
through, and there are at least a few packages that might have perl
module dependancies (doesn't some of the functionality of gimp require a
few perl modules to be installed? pretty sure there is at least a few
mainstream apps that have perl modules they need for some of their
plugins...).
	If it were my call (ha! ok, everyone stop laughing, I know what
that last line was worth) I'd recommend only maintaining those perl
modules that actually are depended on, and even then discouraging the
use of ebuilds for loading perl modules...er, not sure that made sense,
second whack at it...keep around those modules that are needed for other
ebuilds to succeed, but not try and replicate the cpan listings. For
starters, modules get updated sporadically - there are some modules,
still good, that haven't been touched in years because the developer was
done with it. Others get updated a lot, and that could throw a wrench if
you have apps depending on one version.

	My additional two cents (think I'm up to four now) is that perl
modules are good to have in portage when they fulfill a dependancy, but
personally I think it would be dangerous/risky to attempt to maintain an
ebuild tree for perl modules. No offense to those who have made the
ebuilds up to this point (seemant and danamark come to mind from a
recent perusal, among others), but the whole point to the -MCPAN -e
shell is that you are automatically filtering yourself into the mirror
trees and aren't relying on the main cpan server to handle your request.

	Thinking of which - for apps that depend on perl modules,
instead of building an ebuild for that module that points directly to
the module on cpan, would it be possible to instead execute a one liner
in perl that grabs and installs the module? ( perl -MCPAN -e install
PERL::MODULE)

	Ok, time for more coffee, this thinking stuff hurts.

Mike

On Mon, Jul 08, 2002 at 01:03:42PM +0100, Leon Brocard wrote:
> Michael Cummings sent the following bits through the ether:
> 
> > Like I said, I'm a perl person to, and I'm not trying to rain on
> > anyone's parade, but I think adding the full cpan list is both a
> > reduplication of cpan's efforts and frankly little more than being able
> > to say "I can emerge a module instead of just using perl's built in
> > equivalent of an ebuild".
> 
> I kinda agree. I've just submitted a bunch of Perl ebuilds and mostly
> it's just a case of figuring out the right dependencies and putting
> them in DEPEND. But sometimes, modules have an interactive install by
> default and so I code up a src_compile to get around that.
> 
> The problem (and I've been discussing this with London Perl Mongers
> for the past week or so) is external dependencies, like XML::Parser
> needing expat or XML::LibXML needing libxml. External library
> dependencies aren't part of the Makefile.PL (this is a big problem
> really). Thus I think it makes sense to have Perl module ebuilds (or
> for a least some of the modules). I bet you most people actually use
> less than 100 modules. It may be a good idea to have some of this
> automated too.
> 
> Leon
> 
> ps should we move this to gentoo-dev?
> -- 
> Leon Brocard.............................http://www.astray.com/
> Nanoware...............................http://www.nanoware.org/
> 
> ... Can you repeat the part after "Listen very carefully"?
> _______________________________________________
> gentoo-user mailing list
> gentoo-user@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-user


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [gentoo-dev] Re: perl extra modules
  2002-07-08 12:27             ` [gentoo-dev] Re: perl extra modules Michael Cummings
@ 2002-07-08 15:41               ` Leon Brocard
  2002-07-08 16:02                 ` Michael Cummings
  2002-07-08 16:22                 ` Benjamin Ritcey
  0 siblings, 2 replies; 5+ messages in thread
From: Leon Brocard @ 2002-07-08 15:41 UTC (permalink / raw
  To: gentoo-dev

Michael Cummings sent the following bits through the ether:

> I'd recommend only maintaining those perl modules that actually are
> depended on, and even then discouraging the use of ebuilds for
> loading perl modules

Right. There's the problem of thousands of out-of-date ebuilds. I
guess this isn't so much of a problem with the other languages as they
don't have as many modules as are on the CPAN. I think we've discussed
all the issues. What do the gentoo team think we should do? Have lots
of ebuilds? Use CPAN.pm or CPANPLUS instead? Somewhere inbetween?

Leon
-- 
Leon Brocard.............................http://www.astray.com/
Nanoware...............................http://www.nanoware.org/

... Ethernet: A device for catching the Ether Bunny


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [gentoo-dev] Re: perl extra modules
  2002-07-08 15:41               ` Leon Brocard
@ 2002-07-08 16:02                 ` Michael Cummings
  2002-07-08 20:35                   ` Robert Coie
  2002-07-08 16:22                 ` Benjamin Ritcey
  1 sibling, 1 reply; 5+ messages in thread
From: Michael Cummings @ 2002-07-08 16:02 UTC (permalink / raw
  To: gentoo-dev

Leon,
	Spoke with seemant about this this morning, and am looking at
modifying the eclass for module support. I need to work out a few bugs
in the cpan config. Will keep you posted,

Mike

On Mon, Jul 08, 2002 at 04:41:59PM +0100, Leon Brocard wrote:
> Right. There's the problem of thousands of out-of-date ebuilds. I
> guess this isn't so much of a problem with the other languages as they
> don't have as many modules as are on the CPAN. I think we've discussed
> all the issues. What do the gentoo team think we should do? Have lots
> of ebuilds? Use CPAN.pm or CPANPLUS instead? Somewhere inbetween?


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [gentoo-dev] Re: perl extra modules
  2002-07-08 15:41               ` Leon Brocard
  2002-07-08 16:02                 ` Michael Cummings
@ 2002-07-08 16:22                 ` Benjamin Ritcey
  1 sibling, 0 replies; 5+ messages in thread
From: Benjamin Ritcey @ 2002-07-08 16:22 UTC (permalink / raw
  To: gentoo-dev

On Mon, 2002-07-08 at 11:41, Leon Brocard wrote:
> Michael Cummings sent the following bits through the ether:
> 
> > I'd recommend only maintaining those perl modules that actually are
> > depended on, and even then discouraging the use of ebuilds for
> > loading perl modules
> 
> Right. There's the problem of thousands of out-of-date ebuilds. I
> guess this isn't so much of a problem with the other languages as they
> don't have as many modules as are on the CPAN. I think we've discussed
> all the issues. What do the gentoo team think we should do? Have lots
> of ebuilds? Use CPAN.pm or CPANPLUS instead? Somewhere inbetween?

I ran across BSDPAN a little while ago - like the CPAN module, but
registers installed perl mods in the BSD PKG_DB

Food for thought, perhaps:

http://www.freebsd.org/cgi/getmsg.cgi?fetch=1253580+1258568+/usr/local/www/db/text/2001/freebsd-ports/20010204.freebsd-ports


HTH,

-b





^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [gentoo-dev] Re: perl extra modules
  2002-07-08 16:02                 ` Michael Cummings
@ 2002-07-08 20:35                   ` Robert Coie
  0 siblings, 0 replies; 5+ messages in thread
From: Robert Coie @ 2002-07-08 20:35 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]


I deploy lots of Linux machines that are delivered to clients with
custom-written software, much of which is in perl and sometimes
depends on various CPAN modules.  To date, I have used Debian for
these sorts of projects, and it has been very helpful to simply make
debian control files that specify dependencies, so that the necessary
modules are installed automatically.

Having moved my personal hosts to Gentoo, I am looking into the
possibility of using Gentoo for new client installs as well, and have
contributed some ebuilds for various CPAN modules that I have found
need for in my work.

I was planning on using a custom "packages" file to simplify
installation of these custom machines, which, I suppose, would not be
feasible if the perl module ebuilds were dropped from the
distribution.  I would hope that whatever solution is agreed on,
people would keep in mind the goal of being able to easily specify for
installation several sets of Perl modules, and it would be nice if
there were support for some sort of dependency checking, as would be
provided for free by portage if the modules had ebuilds.

-- 
Robert Coie <rac@apropos.co.jp>
Implementor, Apropos Ltd.

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2002-07-08 20:35 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20020707174011.GA19958@lakics.homelinux.net>
     [not found] ` <wxxptxzi82i.fsf@nommo.uio.no>
     [not found]   ` <20020707213230.GA18320@ns0>
     [not found]     ` <20020708000924.1ed1a55d.spider@gentoo.org>
     [not found]       ` <20020708084125.GA32142@ns0>
     [not found]         ` <20020708113220.GA26801@datanode.net>
     [not found]           ` <20020708120342.GA2576@ns0>
2002-07-08 12:27             ` [gentoo-dev] Re: perl extra modules Michael Cummings
2002-07-08 15:41               ` Leon Brocard
2002-07-08 16:02                 ` Michael Cummings
2002-07-08 20:35                   ` Robert Coie
2002-07-08 16:22                 ` Benjamin Ritcey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox