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!
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 database, for example. For this they can't be replaced. It's feasible to do this via environment variables, but users very rarely follow instructions involving environment variables. (See the history of the dbi-users mailing list...)
Re:Couple of items
pdcawley on 2002-07-10T12:39:09
Distribution maintainers do though. Especially if they're Leon.Re:Couple of items
ct on 2002-07-10T14:57:34
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 comparisonI 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 in stages. emerge rsync and you've got the latest tree, emerge --update world and you get upgraded everything. The Gentoo version numbers are the version of the INSTALL media, not the OS that you are running.
It truly is the last dist you will ever need to put on a box. I've got a Redhat 7.1 box living remotely in a friend's basement all the way on the other side of town. To "Upgrade" that, I'd really have to either wrestle with rpms or take the box down and reinstall redhat. If it were gentoo, it would be up to date.
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.
(And, yes, I know that debian can do similar things, and red-carpet can maintain your rpms. I find both to be cumbersome.)
Re:Couple of items
Matts on 2002-07-10T21:40:25
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.Re:Couple of items
acme on 2002-07-11T08:21:35
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 ;-)]Re:Couple of items
Matts on 2002-07-11T09:15:06
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.Re:Couple of items
acme on 2002-07-11T09:55:15
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... ;-)Re:Couple of items
Matts on 2002-07-11T10:21:30
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?Re:Couple of items
ziggy on 2002-07-11T20:41:13
I think that's the wrong question to be asking.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?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 of "stable". Whenever you find a module you consider to be stable and sign it (or sign a proxy for that module), then I have more confidence that this module is stable. Doubly so if any one of us can revoke a signature at some point in the future (when a module is found to have a security whole big enough to pilot the NCC-1701 through).
I freely admit that my knowledge and understanding of a "web of trust" (a la RDF) and cryptographic signatures is very weak. But it's important to look beyond the simple "signed by the maintainer" and "signed by the CPAN librarian" checkboxes for CPAN modules.
Re:Couple of items
ask on 2002-07-15T07:48:13
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 RedHat and using the RedHat network to keep the perl.org boxes updated. It's great. It rocks. It's easy. It works. It's stable.
Of course; we have our own perl build and apache builds (all in/home/perl and rsynced to the boxes that needs it); but for everything else we use RedHat rpms.
- ask
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 ebuilds for everything on CPAN seems to be a herculean task.
Re:Perl in portage.
ziggy on 2002-07-10T15:32:07
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 better port version available for the same source tarball). The best solution I've found is to just deal and install 5.6.1 alongside the system build and managing it separately. (Ditto for OSX and fink.)
So managing two build systems (CPAN and ports/ebuild/apt/etc.) seems to be the easiest way to go, because Perl modules are never seemlessly integrated into a larger build system.
I've been thinking about trying out gentoo. Really since it sounds like Leon has a good chunk of the CPAN/portage integration. :-)
Re:Perl in portage.
ct on 2002-07-10T19:54:18
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.
Re:Perl in portage.
Dom2 on 2002-07-10T21:19:41
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
