Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

acme (189)

acme
  (email not shown publicly)
http://www.astray.com/
Leon Brocard (aka acme) is an orange-loving Perl eurohacker with many varied contributions to the Perl community, including the GraphViz module on the CPAN. YAPC::Europe was all his fault. He is still looking for a Perl Monger group he can start which begins with the letter 'D'.

Journal of acme (189)

Wednesday July 10, 2002
05:54 AM

CPAN in Gentoo

[ #6249 ]
As I've mentioned before, I've been messing around with a new ports-based distribution called Gentoo. Gentoo packages are installed by something called portage, which takes care of dependencies, makes sure configuration files aren't written over, and takes care of bundling up distributions so that they can be easily removed later on.

There are a couple of ebuilds for CPAN modules in Gentoo. However, they're all done by hand and so are all slightly different and some are quite out of date. I got involved in a dicsussion on gentoo-user (and later gentoo-dev and then Gentoo bugzilla) on how the best way to integrate CPAN modules into Gentoo would be.

You can think of this as layering dependencies. The Perl modules have simple dependency information in the PREREQ_PM in Makefile.PLs. However, only dependencies on Perl modules are in there. It so happens that Compress::ZLib needs zlib installed. Thus in the dev-perl/Compress-Zlib ebuild, we have added a dependency on the zlib C library manually by adding '>=sys-libs-zlib-1.1.3' to DEPEND. So that if you try and install Compress::Zlib in Gentoo using "emerge Compress-Zlib" it will make sure you already have the zlib library installed, and if not will go off and install it first.

We initially thought of somehow merging CPAN.pm or CPANPLUS into emerge, but that was perhaps too much work. On the tube home last night, I considered how hard it would be to autogenerate ebuild files for the whole of CPAN. This would have the advantage of always being up to date (good as Gentoo is cutting edge generally) and would probably work for about 80% of modules.

Well, I did it. Read the bugzilla entry for the script, and two sample generated ebuilds. CPANPLUS helped a lot (but it could have helped more ;-). I think this goes most of the way of helping Gentoo keep it's CPAN ebuilds recent and complete. Let's see if we can get it working 100% and live.

My recent post above contains info on how it works and minor problems. Makefile.PLs which contain incorrect dependencies really annoy me. But the most annoying thing is Makefile.PLs that are interactive. Most don't need to be and I think they should be non-interactive by default. This will be my next crusade...

How do other distributions do this anyway? By hand? Yuck!


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

CPAN in Gentoo 14 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Mostly due to your posting and subsequent investigation, I installed Gentoo on one of my machines at work yesterday. It looks very promising, although the move from RPMs is made a little more difficult by the lack of instant gratification. But I can accept that since most of the items that take a while to upgrade don't get upgraded very often.

    Also, I think interactive Makefile.PL routines are only necessary when you need the user to specify some information for testing: a DSN, username and password for a

    • Distribution maintainers do though. Especially if they're Leon.
    • The lack of instant gratification becomes less of a problem the longer you use Gentoo. You gain so much from the process that the drawbacks are small by comparison

      I have never been a fan of RPMs, I usually installed a barebones redhat and compiled my own apache, etc.

      The real key to Gentoo, for me, came when 1.2 was released. I had installed 1.1a. I immediately thought "Whoops, need to upgrade", until people on the gentoo forums pointed out the folly in that assumption. Like the BSDs, you upgrade gentoo

      • One thing that scares me is how do you stick to a stable tested version? That doesn't seem to be something gentoo offers, as it's by end users rather than a company (and doesn't have the rigorous testing debian has). Companies like ours need that kind of long-term stability with just security updates.
        • You'll be happy to know that Gentoo doesn't have a concept of "stable" as such  ;-) Until they have this, I won't be running it on any servers, but I'm quite happy running it on laptops and desktops. Of course, you don't *have* to upgrade to the latest and greatest if you prefer stability, you'll just be slightly out of date.

          [Of course, the CPAN doesn't have this concept either  ;-)]
          • Actually that's not quite true, though because CPAN's an anarchy it's very hit and miss. You can upload something with an underscore in the version to make it an unstable version.
            • You have to admit CPAN has no quality control or a list of modules that others consider to be stable. And while we're at it, where's the digital signatures...  ;-)
              • Yes, I totally agree. There's a *definition* of stable. It's just that you're free to upload modules that aren't without calling them unstable  ;-)

                Hmm, digital signatures. I don't even know how that would work. I mean, which party would you trust - the uploader or the CPAN maintainers?

                • Hmm, digital signatures. I don't even know how that would work. I mean, which party would you trust - the uploader or the CPAN maintainers?

                  I think that's the wrong question to be asking.

                  CPAN with digital signatures would be a better place, whether you trust whoever is designated as the module maintainer, the CPAN maintainers, or not.

                  For example, it's rather easy to imagine a web of trust built up out of the whole CPAN community. I might know you, Schwern, or acme personally and trust your concept

      • That fact, above all else, it what has sold me on Gentoo, lock stock and barrel. An OS that is always as current as you want. Makes redhat look sort of silly.

        Heh. I have been using FreeBSD on servers and some workstations for similar reasons (among others) from early 1999 to earlier this year.

        Yup, I have gone full circle and I am turning back to RedHat. The ports system breaks complicated upgrades far too often. No fun at all.

        With more than a few boxes it becomes unmanageble too.

        How I am using Red
        --

        -- ask bjoern hansen [askbjoernhansen.com], !try; do();

  • I personally use CPAN.pm under Gentoo. I have never used an ebuild for a module. I let portage compile my perl core dist, and use CPAN.pm for the rest. But then, that's what I've always done. I always compiled my own perl and installed my own modules, so this seemed natural to me.

    I'm still in an RPM mindset a bit. I spent most of my time shunning packages put out by redhat, that I still have a bias against perl modules from the core dist.

    I would think that a hybrid solution would be best. Generating ebuil

    • I do similar things with FreeBSD (and now with fink on OS X).

      With FreeBSD, the system perl build is 5.005_03, and doesn't want to upgrade. All of the Perl ports (there are about a bazillion of them in  /usr/ports) all want that managed Perl build (which puts modules in  /usr/libdata). That also brings with it the *BSD ports issue of easy-to-install, hard-to-upgrade (dependencies are linked to particular port versions; ports will try and re-install an installed package just because there's a be

      • I'll beat the dead horse one more time. I can't say enough good things about Gentoo. The only people I wouldn't recommend it to is complete newbies. Anyone with the slightest bit of unix experience should find it simple.

        I also do OpenBSD, and a bit of FreeBSD. I find portage simpler than either system's  /usr/src and  /usr/ports setup.

      • I recently found that the perl port has been made easier to use instead of the system perl in FreeBSD (won't catch me using that Linux thing  ;-) All you need to do is install the perl port and run "use.perl port".

        It's made life a lot easier on my -STABLE boxes. I hate using non packaged software; it descends into unmanageability so quickly it makes me shudder just thinking about it.

        -Dom

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.