Hi folks,
I was just digging through the archives and found some comments from
Sept 2008 about CPAN provider being immature.
What is the current status?
One of the main things I''d like to do with puppet is keep CPAN modules
updated.
thanks,
-Alan
--
“Don''t eat anything you''ve ever seen advertised on TV”
- Michael Pollan, author of "In Defense of Food"
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Tue, Apr 27, 2010 at 5:02 PM, Alan McKay <alan.mckay@gmail.com> wrote:> Hi folks, > > I was just digging through the archives and found some comments from > Sept 2008 about CPAN provider being immature.Personally, I wouldn''t want a CPAN provider -- if you can get content from OS packages (debian is particularly good about this), I would use those. CPAN''s need to build things locally and update at unpredictable intervals (and frequently not building) means I really wouldn''t want to connect a production machine directly to it. Doing really minimal packaging for the CPAN modules you use, if not already packaged, would be worth it in my opinion. --Michael -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, 28 Apr 2010 17:04:30 +0200, Michael DeHaan <michael@puppetlabs.com> wrote:> On Tue, Apr 27, 2010 at 5:02 PM, Alan McKay <alan.mckay@gmail.com> wrote: >> Hi folks, >> >> I was just digging through the archives and found some comments from >> Sept 2008 about CPAN provider being immature. > > Personally, I wouldn''t want a CPAN provider -- if you can get content > from OS packages (debian is particularly good about this)My experience is totally different. Debian is very active as a perl packager, but many module packages are just missing (obviously) or way too old to be useful.> CPAN''s need to build things locally and update at > unpredictable intervalsI don''t understand. You can control exactly when you want to update your index, if that''s what you mean, or when you want to trigger updates.> (and frequently not building)Again, my experience is that pretty much anything builds and tests correctly these days.> means I really wouldn''t want to connect a production machine directly to > it.I understand. But usually if you have a need for CPAN modules, and you are "serious" about it, you either: 1) manage your own CPAN mirror 2) use CPAN::Mini, that gives you full control of which packages your local mirror should include, versions included 3) use local::lib, to make your CPAN environment self-contained and not impacting on your OS-packaged perl and modules> Doing really minimal packaging for the CPAN modules you use, if not > already packaged, would be worth it in my opinion.This way presents its problems too, many dependencies to repackage, and I''d say too much work overall... depends on your needs, ofc. There''s active discussions in the Perl community to build OS-level packaging knowledge inside the current or future CPAN clients. Maybe that''s the best way. -- Cosimo -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, Apr 28, 2010 at 8:24 AM, Cosimo Streppone <cosimo@streppone.it>wrote:> On Wed, 28 Apr 2010 17:04:30 +0200, Michael DeHaan <michael@puppetlabs.com> > wrote: > > On Tue, Apr 27, 2010 at 5:02 PM, Alan McKay <alan.mckay@gmail.com> wrote: >> >>> Hi folks, >>> >>> I was just digging through the archives and found some comments from >>> Sept 2008 about CPAN provider being immature. >>> >> >> Personally, I wouldn''t want a CPAN provider -- if you can get content >> from OS packages (debian is particularly good about this) >> > > My experience is totally different. Debian is very active as a > perl packager, but many module packages are just missing > (obviously) or way too old to be useful. > > > CPAN''s need to build things locally and update at >> unpredictable intervals >> > > I don''t understand. > You can control exactly when you want to update your index, > if that''s what you mean, or when you want to trigger updates. > > (and frequently not building) >> > > Again, my experience is that pretty much anything builds and tests > correctly these days. > > > means I really wouldn''t want to connect a production machine directly to >> it. >> > > I understand. But usually if you have a need for CPAN modules, and > you are "serious" about it, you either: > > 1) manage your own CPAN mirror > > 2) use CPAN::Mini, that gives you full control of which packages > your local mirror should include, versions included > > 3) use local::lib, to make your CPAN environment self-contained > and not impacting on your OS-packaged perl and modules > > > Doing really minimal packaging for the CPAN modules you use, if not >> already packaged, would be worth it in my opinion. >> > > This way presents its problems too, many dependencies to repackage, > and I''d say too much work overall... depends on your needs, ofc. >Repackaging CPAN modules is reasonably trivial, and will give you a more consistent setup than writing a complex CPAN provider. Have you looked at dh-perl-make ? http://www.opensourcery.com/blog/hans-dieter-pearcey/packaging-cpan-modules-debian or even cpan2dist ?> There''s active discussions in the Perl community to > build OS-level packaging knowledge inside the current > or future CPAN clients. > > Maybe that''s the best way. > > -- > Cosimo > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- nigel -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, 28 Apr 2010 17:36:03 +0200, Nigel Kersten <nigelk@google.com> wrote:>> On Tue, Apr 27, 2010 at 5:02 PM, Alan McKay <alan.mckay@gmail.com> >> wrote: >>>> >>>> I was just digging through the archives and found some comments from >>>> Sept 2008 about CPAN provider being immature. >>> >>> Personally, I wouldn''t want a CPAN provider -- if you can get content >>> from OS packages (debian is particularly good about this) >>> >>> [...] >>> Doing really minimal packaging for the CPAN modules you use, if not >>> already packaged, would be worth it in my opinion. >> >> This way presents its problems too, many dependencies to repackage, >> and I''d say too much work overall... depends on your needs, ofc. > > Repackaging CPAN modules is reasonably trivial, and will give you a more > consistent setup than writing a complex CPAN provider. > > Have you looked at dh-perl-make ?We''re using dh-make-perl, and it doesn''t handle dependencies that are not already packaged, IIRC.> http://www.opensourcery.com/blog/hans-dieter-pearcey/packaging-cpan-modules-debianI''ll read it, thanks. Skimming through it, it seems the author is aware of the limitations I was pointing out (having to maintain debian control files, etc...)> or even cpan2dist ?I think I looked at it long time ago. Maybe time to see if it got updates. Thanks, -- Cosimo -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, Apr 28, 2010 at 11:04 AM, Michael DeHaan <michael@puppetlabs.com> wrote:> Doing really minimal packaging for the CPAN modules you use, if not > already packaged, would be worth it in my opinion.So how do you mean? One thing I was thinking of is building once on a central machine and then sticking it from there into puppet to distribute as a filesystem. But I''d have to take care about 32/64 bits and OS differences. -- “Don''t eat anything you''ve ever seen advertised on TV” - Michael Pollan, author of "In Defense of Food" -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, Apr 28, 2010 at 12:04 PM, Alan McKay <alan.mckay@gmail.com> wrote:> On Wed, Apr 28, 2010 at 11:04 AM, Michael DeHaan <michael@puppetlabs.com> wrote: >> Doing really minimal packaging for the CPAN modules you use, if not >> already packaged, would be worth it in my opinion. >I''m biased towards, when possible, distributing package content via RPM or deb ... but ideally, those too. You are free to ignore that, but those are my preferences. If a CPAN library requires libcurl and libcurl isn''t installed, that''s something the OS package manager can deal with for you. I like having all my dependencies in the system, in other words, and also having (where possible) only one package manager.> So how do you mean? One thing I was thinking of is building once on a > central machine and then sticking it from there into puppet to > distribute as a filesystem. But I''d have to take care about 32/64 > bits and OS differences.Well, there are noarch packages, but for those that contain native code, yes. I prefer not to do builds on production machines. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> I''m biased towards, when possible, distributing package content via > RPM or deb ... but ideally, those too. You are free to ignore that, > but those are my preferences.It is also mine, but about 30 of the packages our code uses are not found in the CentOS RPMs. I''ve been looking at every imaginable way to manage CPAN nicely, and it just seems like a mess. I''ve even subscribed to the cpan mailing list and ask there, and they do not seem to have any clean solutions that will allow me manage CPAN across a network without having to go through the 50 questions routine for each machine (e.g. autobundle). I even tried expect to take care of that, but no luck. Also cpan::mini to make my own repository. Tried manually building. Still cannot find something. So I picked up puppet again (something I want to get going even if I cannot find a way for it to manage my CPAN mess) But back to your point - if I could do this with yum I would be the happiest guy in the world! It would be so easy to do, and I could add it to my kickstart files. There were a few new ideas in this thread which I have not yet seen - so I''ll see where they lead me. thanks all, -Alan -- “Don''t eat anything you''ve ever seen advertised on TV” - Michael Pollan, author of "In Defense of Food" -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, Apr 28, 2010 at 8:52 AM, Cosimo Streppone <cosimo@streppone.it>wrote:> On Wed, 28 Apr 2010 17:36:03 +0200, Nigel Kersten <nigelk@google.com> > wrote: > > On Tue, Apr 27, 2010 at 5:02 PM, Alan McKay <alan.mckay@gmail.com> >>> wrote: >>> >>>> >>>>> I was just digging through the archives and found some comments from >>>>> Sept 2008 about CPAN provider being immature. >>>>> >>>> >>>> Personally, I wouldn''t want a CPAN provider -- if you can get content >>>> from OS packages (debian is particularly good about this) >>>> >>>> [...] >>>> >>>> Doing really minimal packaging for the CPAN modules you use, if not >>>> already packaged, would be worth it in my opinion. >>>> >>> >>> This way presents its problems too, many dependencies to repackage, >>> and I''d say too much work overall... depends on your needs, ofc. >>> >> >> Repackaging CPAN modules is reasonably trivial, and will give you a more >> consistent setup than writing a complex CPAN provider. >> >> Have you looked at dh-perl-make ? >> > > We''re using dh-make-perl, and it doesn''t handle dependencies > that are not already packaged, IIRC.sure. Is it really that much more work to insert appropriate dependencies compared to the alternatives though? It should also be relatively easy to change the way the dependencies are done such that even if it can''t find the relevant packages it would know what they should be called though right?> > > >> http://www.opensourcery.com/blog/hans-dieter-pearcey/packaging-cpan-modules-debian >> > > I''ll read it, thanks. > > Skimming through it, it seems the author is aware > of the limitations I was pointing out (having to maintain debian > control files, etc...) >If I cared about cpan these days I''d be looking at patching dh-make-perl to support generating the dependencies even if they don''t exist yet. We do a similar thing here internally with packaging gems as debs.> > or even cpan2dist ? >> > > I think I looked at it long time ago. > Maybe time to see if it got updates. > > Thanks, > > > -- > Cosimo > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- nigel -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Not to mention the RedHat Perl distribution has been notoriously bad. I know the last 5.8.8 release still shipped without weak reference support. Try to install Moose or any Modern Perl Module, without weak reference support! I''m moving to building my own Perl installed in /opt/local/perl and then I''ll setup a CPAN::Mini site. I''ll use Puppet to push the CPAN::Config.pm to all my boxes to use the local repository. I''ll need to setup something to monitor CPAN for updates to packages I''m mirroring locally. There are several projects that I''m working on that will require a "Perl Environment Freeze." Those will be separate CPAN::Config.pm''s. That''s one of my next projects, so I''ll let you know how it goes. I''m a Perl programmer at heart, which means I''m lazy, which means I''ll have the "add module + dependencies to local cpan::mini repository scripted (if it''s not already)." On Wed, Apr 28, 2010 at 12:58 PM, Nigel Kersten <nigelk@google.com> wrote:> > > On Wed, Apr 28, 2010 at 8:52 AM, Cosimo Streppone <cosimo@streppone.it>wrote: > >> On Wed, 28 Apr 2010 17:36:03 +0200, Nigel Kersten <nigelk@google.com> >> wrote: >> >> On Tue, Apr 27, 2010 at 5:02 PM, Alan McKay <alan.mckay@gmail.com> >>>> wrote: >>>> >>>>> >>>>>> I was just digging through the archives and found some comments from >>>>>> Sept 2008 about CPAN provider being immature. >>>>>> >>>>> >>>>> Personally, I wouldn''t want a CPAN provider -- if you can get content >>>>> from OS packages (debian is particularly good about this) >>>>> >>>>> [...] >>>>> >>>>> Doing really minimal packaging for the CPAN modules you use, if not >>>>> already packaged, would be worth it in my opinion. >>>>> >>>> >>>> This way presents its problems too, many dependencies to repackage, >>>> and I''d say too much work overall... depends on your needs, ofc. >>>> >>> >>> Repackaging CPAN modules is reasonably trivial, and will give you a more >>> consistent setup than writing a complex CPAN provider. >>> >>> Have you looked at dh-perl-make ? >>> >> >> We''re using dh-make-perl, and it doesn''t handle dependencies >> that are not already packaged, IIRC. > > > sure. Is it really that much more work to insert appropriate dependencies > compared to the alternatives though? > > It should also be relatively easy to change the way the dependencies are > done such that even if it can''t find the relevant packages it would know > what they should be called though right? > > >> >> >> >>> http://www.opensourcery.com/blog/hans-dieter-pearcey/packaging-cpan-modules-debian >>> >> >> I''ll read it, thanks. >> >> Skimming through it, it seems the author is aware >> of the limitations I was pointing out (having to maintain debian >> control files, etc...) >> > > If I cared about cpan these days I''d be looking at patching dh-make-perl to > support generating the dependencies even if they don''t exist yet. We do a > similar thing here internally with packaging gems as debs. > > >> >> or even cpan2dist ? >>> >> >> I think I looked at it long time ago. >> Maybe time to see if it got updates. >> >> Thanks, >> >> >> -- >> Cosimo >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-users@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> >> > > > -- > nigel > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. >-- Brad Lhotsky -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, Apr 28, 2010 at 1:13 PM, Brad Lhotsky <brad.lhotsky@gmail.com> wrote:> Not to mention the RedHat Perl distribution has been notoriously bad. I > know the last 5.8.8 release still shipped without weak reference support. > Try to install Moose or any Modern Perl Module, without weak reference > support!Hmmmm, interesting because we are just pushing forward with a new project based on Moose> I''m moving to building my own Perl installed in /opt/local/perl and then > I''ll setup a CPAN::Mini site. I''ll use Puppet to push the CPAN::Config.pm > to all my boxes to use the local repository. I''ll need to setup something > to monitor CPAN for updates to packages I''m mirroring locally.For me I don''t even care about updates. We generally do not want any updates on RPMs or CPAN without spinning them through a thorough test cycle, so we don''t want anything updated automatically.> There are several projects that I''m working on that will require a "Perl > Environment Freeze." Those will be separate CPAN::Config.pm''s. > That''s one of my next projects, so I''ll let you know how it goes. I''m a > Perl programmer at heart, which means I''m lazy, which means I''ll have the > "add module + dependencies to local cpan::mini repository scripted (if it''s > not already)."Please keep me posted!!! -- “Don''t eat anything you''ve ever seen advertised on TV” - Michael Pollan, author of "In Defense of Food" -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Traditionally i haved rolled mine into rpms for deployment. Over time this can create a rather large private repo. There is also a third party repo which may help (rpmforge), but im unsure of your policy regarding foreign rpms. They do have a great deal of the cpan modules already in rpm format. A simpler method would be to create a dependency rpm which has the files you need for that architecture/os. There is also a puppet centric method im sure. -----Original Message----- From: Alan McKay <alan.mckay@gmail.com> Sent: Wednesday, April 28, 2010 9:43 AM To: puppet-users@googlegroups.com Subject: Re: [Puppet Users] status of cpan provider?> I''m biased towards, when possible, distributing package content via > RPM or deb ... but ideally, those too. You are free to ignore that, > but those are my preferences.It is also mine, but about 30 of the packages our code uses are not found in the CentOS RPMs. I''ve been looking at every imaginable way to manage CPAN nicely, and it just seems like a mess. I''ve even subscribed to the cpan mailing list and ask there, and they do not seem to have any clean solutions that will allow me manage CPAN across a network without having to go through the 50 questions routine for each machine (e.g. autobundle). I even tried expect to take care of that, but no luck. Also cpan::mini to make my own repository. Tried manually building. Still cannot find something. So I picked up puppet again (something I want to get going even if I cannot find a way for it to manage my CPAN mess) But back to your point - if I could do this with yum I would be the happiest guy in the world! It would be so easy to do, and I could add it to my kickstart files. There were a few new ideas in this thread which I have not yet seen - so I''ll see where they lead me. thanks all, -Alan -- “Don''t eat anything you''ve ever seen advertised on TV” - Michael Pollan, author of "In Defense of Food" -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Something to keep in mind is that if you are making your own package repo for Perl RPMS (or any other type of package), you may want to try to get them upstream in a repo. It''s not very difficult to become a Fedora/EPEL maintainer. I would assume Debian has methods to manage packages that also include a fairly low barrier to entry. Part of the drive of the puppet project is to provide re-usable infrastructure. An easy way to do that is get packages we all create into operating system packages repositories, pending good licenses and such of course. That way we can all benefit from these packages. I know that I have put over 25 packages into EPEL simply because I needed them at my day job, and decided if I had to maintain the package once, I may as well do that for everyone else. I am certainly not saying there shouldn''t be a CPAN provider. But I really prefer OS packages. stahnma -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Sat, May 1, 2010 at 10:52 PM, Michael Stahnke <mastahnke@gmail.com> wrote:> know that I have put over 25 packages into EPEL simply because I > needed them at my day job, and decided if I had to maintain the > package once, I may as well do that for everyone else.Yes, this is a very good point Michael and I''d be up for that if I were to go this route. Do you have a recipe or template of some sort that you use for turning CPAN packages into RPMs? -- “Don''t eat anything you''ve ever seen advertised on TV” - Michael Pollan, author of "In Defense of Food" -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Alan McKay <alan.mckay@gmail.com> writes:> On Sat, May 1, 2010 at 10:52 PM, Michael Stahnke <mastahnke@gmail.com> wrote: > >> know that I have put over 25 packages into EPEL simply because I >> needed them at my day job, and decided if I had to maintain the >> package once, I may as well do that for everyone else. > > Yes, this is a very good point Michael and I''d be up for that if I > were to go this route. > > Do you have a recipe or template of some sort that you use for turning > CPAN packages into RPMs?Google for ''cpan to rpm'', and the first tool offered does a fine job. Alternately, CPANPLUS can produce RPM distributions, if you prefer a more generic tool. Daniel -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.