Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Perl Modules as RPM Packages

michael posted more than 11 years ago | from the my-own-catapult dept.

Red Hat Software 207

libertynews writes "KPLUG President Kevin Pedigo has just announced his latest project -- RPMPAN, an archive of CPAN Perl modules in RPM format, generated nightly."

cancel ×

207 comments

Sorry! There are no comments related to the filter you selected.

GNAA Announces acquisition of SCO (-1, Troll)

Anonymous Coward | more than 11 years ago | (#6771278)

GNAA Announces acquisition of SCO
By Tim Copperfield
New York, NY - GNAA (Gay Nigger Association of America) today announced acquisition of The SCO Group [yahoo.com] for $26.9 million in stock and $40 million in gay niggers.

GNAA today announced it has signed a definitive agreement to acquire the intellectual property and technology assets of The SCO Group, a leading provider of Fear, Uncertainty and Doubt, based in Lindon, Utah. GNAA's acquisition of SCO technology will help GNAA sign up more members worldwide. In addition to developing new solutions, GNAA will use SCO engineering expertise and technology to enhance the GNAA member services.

"I'd love to see these GNAA types slowly consumed by millions of swarming microbes and converted into harmless and useful biochemicals." said an anonymous slashdot poster, blinded by the GNAA success in achieving first post on a popular geek news website, slashdot.org [slashdot.org] .

"This GNAA shit is getting out of hand. Slashdot needs troll filters. Or better yet a crap flood mod that I can exclude from my browsing. Seriously, a good troll is art, what you dumb fucks are doing is just plain stupid." said spacecowboy420.

macewan, on linuxquestions [linuxquestions.org] said "Thanks for that link to the SCO quotes page. My guess is that they want to be bought out. Hrm, think they want GNAA to buy them??"

After careful consideration and debate, GNAA board of directors agreed to purchase 6,426,600 preferred shares and 113,102 common shares (the equivalent of 150,803 ADSs) of SCO, for an aggregate consideration of approximately US$26.9 million and approximately $40 million for gay niggers that were working in Lindon, Utah offices of The SCO Group.

If all goes well, the final decision is to be expected shortly, followed by transfer of most SCO niggers from their Lindon, UT offices to the GNAA Headquarters in New York.

About GNAA
GNAA (GAY NIGGER ASSOCIATION OF AMERICA) is the first organization which
gathers GAY NIGGERS from all over America and abroad for one common goal - being GAY NIGGERS.

Are you GAY [klerck.org] ?
Are you a NIGGER [mugshots.org] ?
Are you a GAY NIGGER [gay-sex-access.com] ?

If you answered "Yes" to any of the above questions, then GNAA (GAY NIGGER ASSOCIATION OF AMERICA) might be exactly what you've been looking for!
Join GNAA (GAY NIGGER ASSOCIATION OF AMERICA) today, and enjoy all the benefits of being a full-time GNAA member.
GNAA (GAY NIGGER ASSOCIATION OF AMERICA) is the fastest-growing GAY NIGGER community with THOUSANDS of members all over United States of America. You, too, can be a part of GNAA if you join today!

Why not? It's quick and easy - only 3 simple steps!

First, you have to obtain a copy of GAY NIGGERS FROM OUTER SPACE THE MOVIE [imdb.com] and watch it.

Second, you need to succeed in posting a GNAA "first post" on slashdot.org [slashdot.org] , a popular "news for trolls" website

Third, you need to join the official GNAA irc channel #GNAA on EFNet, and apply for membership.
Talk to one of the ops or any of the other members in the channel to sign up today!

If you are having trouble locating #GNAA, the official GAY NIGGER ASSOCIATION OF AMERICA irc channel, you might be on a wrong irc network. The correct network is EFNet, and you can connect to irc.secsup.org or irc.isprime.com as one of the EFNet servers.
If you do not have an IRC client handy, you are free to use the GNAA Java IRC client by clicking here [nero-online.org] .

About SCO
The SCO Group [SCOX [yahoo.com] ] helps millions of gay niggers in more than 82 countries around the world grow their penises everyday. Headquartered in Lindon, Utah, SCO has a network of more than 11,000 nigger resellers and 8,000 developers. SCO Global Services provides reliable nigger support and services to prospective members and customers.
SCO and the associated SCO logo are trademarks or registered trademarks of The SCO Group, Inc. in the U.S. and other countries. UNIX and UnixWare are registered trademarks of The Open Group in the United States and other countries. All other brand or product names are or may be trademarks of their respective owners.

This news release contains forward-looking statements that involve risks, uncertainties and assumptions. All statements other than statements of historical fact are statements that could be deemed forward-looking statements. These statements are based on management's current expectations and are subject to uncertainty and changes in circumstances. Actual results may vary materially from the expectations contained herein. The forward-looking statements contained herein include statements about the consummation of the transaction with SCO and benefits of the pending transaction with SCO. Factors that could cause actual results to differ materially from those described herein include the inability to obtain regulatory approvals and the inability to successfully integrate the SCO business. GNAA is under no obligation to (and expressly disclaims any such obligation to) update or alter its forward-looking statements, whether as a result of new information, future events or otherwise.


If you have mod points and would like to support GNAA, please moderate this post up.

________________________________________________
| ______________________________________._a,____ |
| _______a_._______a_______aj#0s_____aWY!400.___ |
| __ad#7!!*P____a.d#0a____#!-_#0i___.#!__W#0#___ |
| _j#'_.00#,___4#dP_"#,__j#,__0#Wi___*00P!_"#L,_ |
| _"#ga#9!01___"#01__40,_"4Lj#!_4#g_________"01_ |
| ________"#,___*@`__-N#____`___-!^_____________ |
| _________#1__________?________________________ |
| _________j1___________________________________ |
| ____a,___jk_GAY_NIGGER_ASSOCIATION_OF_AMERICA_ |
| ____!4yaa#l___________________________________ |
| ______-"!^____________________________________ |
` _______________________________________________'

FUCK THE GNAA--JOIN BPAA!!! (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#6771619)

Join BPAA Today!

BPAA (BISEXUAL POLYNESIAN ASSOCIATION OF AMERICA) is the first organization which gathers BISEXUAL POLYNESIANS from all over America and abroad for one common goal: Being BISEXUAL POLYNESIANS.

Are you BISEXUAL?
Are you a POLYNESIAN?
Are you a BISEXUAL POLYNESIAN?

If you answered "Yes" to any of the above questions, then BPAA (BISEXUAL POLYNESIAN ASSOCIATION OF AMERICA) might be exactly what you've been looking for! Join BPAA (BISEXUAL POLYNESIAN ASSOCIATION OF AMERICA) today, and enjoy all the benefits of being a full-time BPAA member.
BPAA (BISEXUAL POLYNESIAN ASSOCIATION OF AMERICA) is the fastest-growing BISEXUAL POLYNESIAN community with THOUSANDS of members all over United States of America. You, too, can be a part of BPAA if you join today!

Why not? It's quick and easy--only 2 simple steps!

Talk to one of the ops or any of the other members in the channel to sign up today!

If you are having trouble locating #BPAA, the official BISEXUAL POLYNESIAN ASSOCIATION OF AMERICA irc channel, you might be on a wrong irc network. The correct network is EFNet, and you can connect to irc.secsup.org [secsup.org] or irc.isprime.com [isprime.com] as one of the EFNet servers.

If you have mod points and would like to support BPAA, please moderate this post up.

This post brought to you by a proud member of BPAA

` __________________________________________________ ______
| ______________________________________._a,________ _____ |
| _________________________aj#0s_____aWY!400._______ _____ |
| __ad#7!!*P_____.d#0a____#!-_#0i___.#!__W#0#_______ _____ |
| _j#'___0#,___4#dP_"#,__j#,__0#Wi___*00P!_"#L,_____ _____ |
| _"#g____01___"#01__40,_"4Lj#!_4#g_________"01_____ _____ |
| __oe__tyugk____*@`gpdNl_______-!^_________________ _____ |
| ___lkp____ghq___pTW_______________________________ _____ |
| ____mw_____ff___oef_______________________________ _____ |
| _____er__ww_______________________________________ _____ |
| ______xde___BISEXUAL_POLYNESIAN_ASSOCIATION_OF_AME RICA_ |
| __________________________________________________ _____ |
` __________________________________________________ ______'

bpaa representative #648437

developers (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#6771279)

"Developers! Developers! Developers!" -- Steve Balmer, Microsoft Corporation.

perl with RPM lovin' ? (5, Funny)

imag0 (605684) | more than 11 years ago | (#6771291)

I can see where this can go wrong...

# rpm -i myperl.rpm

warning: libsomeshit.so not installed

# rpm -i --force myperl.rpm

warning: libsomeshit.so not installed

# rpm -i --force --nodeps myperl.rpm

segfault. core dumped.

# rm -rf /

Re:perl with RPM lovin' ? (5, Funny)

Aliencow (653119) | more than 11 years ago | (#6771306)

It's more like:
# rpm -Uvh myperl.rpm
warning: libsomeshit.so not installed
# rpm -Uvh myperl.rpm someshitlib.rpm
warning: libXML is missing
# rpm -Uvh myperl.rpm someshitlib.rpm libxml.rpm
warning: mozilla is missing

Then you go berserk. You mirror rpmfind, rpm -Uvh *.rpm, end up with multiple versions of crap in different places, and corrupt the UNIVERSE.

Re:perl with RPM lovin' ? (0)

Anonymous Coward | more than 11 years ago | (#6771340)

Yeah, I thought shared libraries were supposed to make life easier. Remember how Microsoft used to be criticized for DLL hell?

Recently I wanted to install a newer copy of Lynx (the text mode web browser). So I get a copy from a Red Hat mirror. I go to install it and it depends on at least *twenty* different libraries (lots of junk like Kerberos -- what th fuck?) Maybe more when you start recursively working your way through the prerequisites. Red Hat Lynx checks in at over 1.5 megabytes. I think that the Opera graphical browser is smaller.

The irony is that shared libraries make it *very* difficult to do a real small stripped down Red Hat installation. There are too many cascading dependencies. You would be better off compiling the stuff you want statically. You'd save space.

Re:perl with RPM lovin' ? (4, Interesting)

cowbutt (21077) | more than 11 years ago | (#6771571)

The irony is that shared libraries make it *very* difficult to do a real small stripped down Red Hat installation.

It didn't take me too long (and hour or so, maybe) to get a minimal server-ready RH8 installation down to 300MB. If I removed the documentation under /usr/share/doc and a few other bits, I could probably get that down to about 222MB (this figure includes Perl and a bunch of commonly-used CPAN modules, BTW, so it's actually a trade-off between "minimal" and "actually-useful" ;-)

You can find the kickstart file in this thread [google.com] .

There are too many cascading dependencies. You would be better off compiling the stuff you want statically. You'd save space.

Yeah, and then when a security problem is found, you end up having to re-compile the lot. Eww.

--

Re:perl with RPM lovin' ? (4, Funny)

evil_roy (241455) | more than 11 years ago | (#6771647)

Now don't go countering all this FUD with facts. This is /. .Anti rpm posts are very important, it is yet another bias that helps the zealots feel better than others.

Re:perl with RPM lovin' ? (1)

Arandir (19206) | more than 11 years ago | (#6771392)

I hope you're exaggerating. I haven't used an RPM based system in years, but it was minor cases of this sort of rot that caused me to switch to Slackware (I'm now using FreeBSD). But somehow if it were true, I don't think I would be surprised.

Re:perl with RPM lovin' ? (4, Insightful)

cowbutt (21077) | more than 11 years ago | (#6771559)

Then you go berserk. You mirror rpmfind, rpm -Uvh *.rpm, end up with multiple versions of crap in different places, and corrupt the UNIVERSE.

I know you're exaggerating for dramatic effect, but therein lies your problem. If you're installing random packages from rpmfind.net, you deserve everything you get. Either stick to packages in your distro's native format and created for the version of the distro you're running (errata, install discs, freshrpms.net in that order) or build your own, newer packages, using your distro vendors src.rpms as a template.

If you do this, I promise you'll encounter zero problems.

Too many people think that RPMs are magically some kind of universal package. They aren't and were never intended to be.

--

-1 Troll (5, Insightful)

danyoung (543350) | more than 11 years ago | (#6771365)

# rpm -i myperl.rpm warning: libsomeshit.so not installed

Uh, I'd just do:

# yum install myperl.rpm
Resolving dependencies
libsomeshit-1.0 needs be installed. OK? (y/n)?
What's the problem again?

Re:-1 Troll-"1 down 999 reasons to go." (0)

Anonymous Coward | more than 11 years ago | (#6771468)

CURSE YOU! Curse you all to hell. The one thing preventing global domination has been removed. ARRRGGGHHH!

Re:perl with RPM lovin' ? (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#6771516)

It is suprising to me that so many meaningless events make their way into the daily news, yet the single most important event in the history of "computer law" is occuring right now (and has been for years) yet goes largely unnoticed. The outcome of the US Department Of Justice's case versus the Microsoft Corporation will have resounding effects upon how we use our computers, whether at work or for play, for years to come. Why does Britany Spear's relationship with the guy from 98 Degrees, or whatever, fill more internet whitespace then this case? Microsoft has been found guilty of acting in an inappropriate manner towards their competition. Microsoft was found to have maintained a monopoly over the PC and web browser market through the use of illegal and unethical business tactics. This decision was upheld in a court of appeals. Microsoft "eliminated" the threat of comeptition through some of the most infamous and vile tactics ever seen in the history of a free market. Microsoft has destroyed companies not with the quality of their software, but rather by applying the kinds of pressure that only an illegal monopoly could wield. Competition needs to be restored to the market of computer desktops, software, and operating systems. The people deserve a choice and a say in the products that they use, and companies other then Microsoft should be allowed to deliver these choices to the people. Regardless of the facts and consequences, the DOJ is prepared to let Microsoft off with a slap on the wrist.

The aspect of a Microsoft monopoly will insure that you will continue to be stuck with an operating system that is completely transparent and flawed. The software that routinely crashes on you while you at work writing up an important memo or at home while surfing the web will continue to be forced upon you - at a price. Due to the ever increasing need for more power out of your PC, due to code bloat and poor process handaling, it is assured that you will have to continue to upgrade your expensive hardware annually. Microsoft's new license laws upon their software and their policy of dropping support on older version of Windows will guarantee that you must purchase their new operating systems. Because of it's (Microsoft) hold over the workstation market, much of your tax dollars goes towards these expensive licenses as they strangle government offices. Many a tax payer dollar goes to the paychecks of the IT staffers needed to support the buggy and insecure NT and Windows 2000 servers, servers that serve as home to yet more buggy and insecure software, which in needs support personel as well. It is a needless cycle that can only be broken if the people stand up against Microsoft.

Visit the Department Of Justice [usdoj.gov] website concerning this case and famailarize yourself with it. Read the comments made by prominent leaders [usdoj.gov] in the information technology field and read about what they have to say concerning the proposed punishment for Microsoft. Write to your law makers and tewll them that you do not want to have to the Microsoft tax any longer.

Re:perl with RPM lovin' ? (4, Informative)

Anonymous Coward | more than 11 years ago | (#6771579)

Oh yeah, like any other package system is different. You want to experience the same fun on FreeBSD? Try the following which I did last week:

portinstall -v p5-DateTime-Format-ISO8601

Pretty innocent right? I mean what the fuck is involved in parsing dates? The library *I* wrote to parse an ISO8601 subset was about two pages long. You know, dates/times like '2003-05-24' '05-25' 'T12:23:45Z' etc.

Well, after a "little while" here's what it pulled in:

p5-Archive-Tar-1.03
p5-Attribute-Handlers-0.78
p5-Class-Factory-Util-1.4
p5-Class-Singleton-1.0 3
p5-Compress-Zlib-1.22
p5-DateTime-0.16
p5-Dat eTime-Format-Builder-0.75
p5-DateTime-Format-ISO8 601-0.03
p5-DateTime-Format-Strptime-1.0302
p5-D ateTime-Locale-0.03
p5-DateTime-TimeZone-0.25
p5 -ExtUtils-ParseXS-2.02
p5-File-Find-Rule-0.11
p5 -IO-stringy-2.108
p5-Module-Build-0.19
p5-Number -Compare-0.01
p5-Params-Validate-0.64
p5-Pod-Esc apes-1.03
p5-Pod-Simple-0.96
p5-Test-Builder-Tes ter-0.09
p5-Test-Harness-2.28
p5-Test-Pod-0.95
p5-Test-Simple-0.47_1
p5-Text-Glob-0.05
p5-Text- Tabs+Wrap-2001.0929
p5-Time-Local-1.07
p5-YAML-0 .35

Can't wait to install some of these Perl RPMs on my Red Hat box........ (in this sentence, "can't wait" means "I'm not going to fucking touch this crap")

Huh? (4, Insightful)

eln (21727) | more than 11 years ago | (#6771294)

How hard is it to install CPAN modules in the first place? This seems like a solution without a problem to me.

Maybe if it were easier to navigate than true CPAN, but according to that page, the way to find your module is by the first letter of that module. So what happened to browsing modules by category? This thing is useless if I need a module for a specific purpose, but I don't know the name of the specific module I'll need.

So, not only are they converting Perl modules to a format they don't really need to be in, but they're making the thing harder to use than CPAN is already.

Re:Huh? (4, Insightful)

Aliencow (653119) | more than 11 years ago | (#6771314)

I find it practical to have everything on the system as the same type of packages. It makes it easier to manage dependencies and updates...

Re:Huh? (1)

GigsVT (208848) | more than 11 years ago | (#6771362)

And also will allow it to be installed using normal tools like apt, instead of screwed up tools that try 6 different protocols to download, of which maybe 3 will work, the rest taking 60 seconds to time out.

Re:Huh? (2, Insightful)

Micah (278) | more than 11 years ago | (#6771321)

No real disagreements, but it *is* nice to have this sort of stuff managed by your package manager.

Re:Huh? (4, Informative)

jsprat (442568) | more than 11 years ago | (#6771364)

it *is* nice to have this sort of stuff managed by your package manager.


Yes, it is. Check out cpan2rpm [cpan.org] .

The best of both worlds - modules built locally, with rpm ease of installation and de-installation.

And whose fault is that? (0, Troll)

Magic Thread (692357) | more than 11 years ago | (#6771349)

Re:Huh? (4, Interesting)

NightSpots (682462) | more than 11 years ago | (#6771374)

Two things:

1) CPAN isn't flawless: yesterday, I tried using it to install File::Temp and it tried upgrading perl from 5.6 to 5.8. That simply isn't the correct thing to do, under any circumstance.

2) Having used FreeBSD, which has perl modules in the ports/package system, I can absolutely say that it's a nice thing to have. Being able to pkg_add a perl module in half a second, no compile time, no dependency hell, it's a good thing.

Re:Huh? (4, Informative)

Bluetrust25 (647829) | more than 11 years ago | (#6771560)

> 1) CPAN isn't flawless: yesterday, I tried using it to install File::Temp and it tried upgrading perl from 5.6 to 5.8. That simply isn't the correct thing to do, under any circumstance.

I've found through experience with just this very thing that the first command run through CPAN should be:

perl -MCPAN -e shell
install Bundle::CPAN

Upgrading to the newest version is necessary to get it to leave perl the hell alone.

So once you get past that hurdle, I find the worst part about CPAN is that some packages which everyone uses like mod_perl, DBI, and DBD::mysql fail to install unless Apache was compiled the correct way and currently running, or MYSQL is running and allows some bullshit nameless user to access all databases (!)

In RedHat Linux 7.x (maybe 8.x and later too), the mod_perl RPM is installed by default, but Apache isn't compiled correct to play nicely with it. So if you want to actually use mod_perl's features (i.e. install Bundle::apache in CPAN) then you have to uninstall apache and compile it by hand.

Frustrat-o-rama.

But in general, CPAN rocks. If it wasn't for CPAN then perl wouldn't be as popular as it is today. Why, just earlier this evening I was thinking that I'd love for users of a web app I'm working on to be able to import data from Excel files rather than just comma-delimited, I did a quick search at search.cpan.org and WHAM, one 'install Spreadsheet::ParseExcel::Simple' later and now users can upload Excel files. I can't think of any other language that makes it this easy to find and reuse libraries.

CPAN makes me look like I'm really good at what I do.

Re:Huh? (0)

Anonymous Coward | more than 11 years ago | (#6771375)

Depends on the packages. I've never had any problems installing any pure perl modules, but I've had more than my share of headaches getting modules that depend on C to work properly. Then again I'm not convinced RPM would solve this problem either.

21 Die in Brazilian Space Launc Accident (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#6771391)

Hahahahaahh !!!

Re:Huh? (2, Funny)

Ian Bicking (980) | more than 11 years ago | (#6771418)

If you want any programs to be under package control (e.g., Perl applications) it is nice to have their dependencies under package control as well. Otherwise you have to bundle all those dependencies.

It's hard (1)

rkuris (541364) | more than 11 years ago | (#6771461)

First off, the install tests don't always work. Loading the mysql module requires setting up a database first, something you don't know about until all the tests fail. So you have to "install force" and pray it works.

Second, there are LOTS of dependencies between perl modules and system libraries. Often, you'll have the runtimes for the libraries you need, but not the archives, so you can't build the module unless you download a bunch of -devel RPMs.

And, it sure is nice to do "rpm --verify" and verify that your RPMs are untouched.

Re:Huh? (5, Insightful)

Anonymous Coward | more than 11 years ago | (#6771509)

Well, since you are looking for a problem, this is it: We run our servers for 3 years minimum, 5 years ideally. During that time, we may or may not need to do updates (security & bugfixes driving that for the most part). During that time, the server + HW RAID + Backup could fail. During that time, we may need to clone the system. During that time we may have reason to verity the integrity of the files & the system. (You get the idea). During that time you may need to know why the heck file 'foo' is installed on the system, and how to get it to your end user systems (remember, just because it's there doesn't mean YOU put it there - many sites have multiple sysadmins).

RPMs serve as an excellent way to document what's on the system. As a benefit, you can keep them around and repeat the procedure if needed.

Imagine for a moment that you have a live production server that NEEDS to be there; you run nightly full system backups, you have mirrored hot swappable hard disks. Now, something goes wrong and you need to rebuild- terribly wrong, all 15 backup tapes were lost, and the mirrored drives are corrupt; it's 3am and you get the page to come into work. Can you put your system together again? That's but one possible scenario.

Imagine for a moment your sidekick admin, who's since quite, built the system without your knowledge. You need to do that again- what did he do? what's installed? how do you reproduce it? OH, and of course your coworker had almost next to no documentation on what specifically they did.

Having RPMS isn't about the 'ease of install' - installing the software is easy! It's about the ease of ongoing maintenance & accountability for the system. Debian packages fall into the same category.

In addition to above, a more familiar way of looking at it; look at all the crap that builds up in windows as you add/remove software. Eventually, you need to reformat, etc. Installing software on Linux is similar.

3 years down the road... did ...humm... I... arg... install... Time::HiRes?

Re:Huh? (1)

Marsala (4168) | more than 11 years ago | (#6771568)

Erm.

The whole point of this is to make it so that the RPM database can be aware of what software is installed on your system... not to simplify installation.

If RPM was smart enough to actually go look in /usr/lib/ and see what's there instead of just checking it's own DB and just blankly assuming that if something wasn't installed via RPM it must not exist, then you'd be absolutely right and this would be a solution without a problem.

And let me know if/when you figure that problem out. You could do some cool stuff and make Linux (heck, and *nix-ish OS) more admin friendly almost overnight.

Re:Huh? (1)

joeykiller (119489) | more than 11 years ago | (#6771622)

Some (not all) CPAN modules are hard to install. The hardest are always those who involves some C code, that depens on third party libraries.

Try installing the mysql DBD drivers without having installed the mySQL header files first, for instance. It's not obvious that you need those to get some perl drivers installed.

Try installing PerlMagick; even with a working ImageMagick installation on your system, it's not straightforward to get PerlMagick up and running.

There's a whole bunch of modules that always gives me headaches. That's why I've grown fond of Debian, that has a lot of Perl modules I can install with apt-get or dselect.

Re:Huh? (1)

beebware (149208) | more than 11 years ago | (#6771644)

>> Try installing PerlMagick; even with a working ImageMagick installation on your system, it's not straightforward to get PerlMagick up and running.

Tell me about it - I've got ImageMagick all happily running on my RH box at the moment, but can I get PerlMagick to run? Nope... 2 hours last night were wasted on this until I twigged that MovableType also supported NetPBM: I could of clicks and everything was hunky dory.

seems a little wasteful.. (2, Interesting)

nich37ways (553075) | more than 11 years ago | (#6771295)

Why exactly do they need to do this every night??
Surely it would be infinetly simpler to just rsync against the server with the CPAN modules and then only rebuild RPMS for new/modified modules.

You could even use perl to do this...

What exactly was wrong with... (3, Insightful)

ultrapenguin (2643) | more than 11 years ago | (#6771297)

perl -MCPAN -e 'install SomePerlModule'?

It would get compiled for your system, warning you and/or downloading all the required dependencies.

Re:What exactly was wrong with... (2, Funny)

jrp2 (458093) | more than 11 years ago | (#6771345)

I sort of agree, installing using the CPAN tool is pretty easy. But, I maintain some custom install RedHat CDs that need some PMs not installed by RedHat. I have the user install them using the MCPAN tool, but it sure would be easier just adding them to the list of RPMS for anaconda to install at system creation time.

I guess it would also be easier for perl developers creating RPMs to bundle these in with their RPMs for a single RPM based install rather than adding instructions for MCPAN.

I think it is a good thing to do this to make Linux one (albeit very small) step easier. Every little bit helps.

Re:What exactly was wrong with... (1)

ultrapenguin (2643) | more than 11 years ago | (#6771394)

> I sort of agree, installing using the CPAN tool is pretty easy. But, I maintain some custom install RedHat CDs that need some PMs not installed by RedHat. I have the user install them using the MCPAN tool, but it sure would be easier just adding them to the list of RPMS for anaconda to install at system creation time.

Yep, since you are already creating custom install cds, I assume you have the knowledge to roll these modules into RPMs yourself. This "script" he uses is using another script (cpanflute2) to actually create RPMs, what's stopping you from using THAT script to make 5-10 custom RPMs for your install CD instead of this guy wasting bandwidth every day downloading "newest" modules?

Packages of course (0)

Anonymous Coward | more than 11 years ago | (#6771351)

There's actually nothing wrong with it. CPAN has solved all dependency and installation problems very well.

Problem is that with current package managers you have to mark some dependencies.. and you need mark them at least for some special Perl modules too since there are some Perl programs that are important enough to be packaged.

Using this RPM program (or in Gentoo g-cpan.pl) you can install these packages so that all the dependencies are satisfied and they can be marked to be updated when necessary (you get that at least in Gentoo) etc.

You get the power of Perl CPAN + power of packages. That's a lot of power.

Uninstall? (3, Insightful)

jbn-o (555068) | more than 11 years ago | (#6771359)

perl -MCPAN -e 'install SomePerlModule'

CPAN Shell makes installation easy, yes. Now show us what the command for uninstallation is.

Also, it would be helpful if the CPAN Shell command you'll show us could warn of lingering dependencies (where package A strictly depends on B and if you uninstall B you'll be warned that if you proceed package A will not work anymore).

Re:Uninstall? (1, Interesting)

Anonymous Coward | more than 11 years ago | (#6771450)

I've set up a little system to do this. I install all modules to /usr/local/perl (PREFIX=/usr/local/perl LIB=/usr/local/perl/lib). Each module has a file called .packlist that contains all files it installed. I wrote a small script that parses these .packlist files and shows what modules are installed, and optionally lets you delete them. It's quite handy doing things this way.

I've pasted the program at http://rafb.net/paste/results/a2695697.html. [rafb.net] It's horribly hacky in part because I didn't care to figure out pod parsing modules and also because I just sat down and wrote it without thinking about it.

You'll do better to write your own that doesn't make so many assumptions, but it's at least a starting point.

PS: don't blame me if it kills your computer. Also, I don't know how long this paste site keeps pastes, so if that URL is broken, well, you shoulda gotten here earlier!

Re:Uninstall? (0)

Anonymous Coward | more than 11 years ago | (#6771645)

Also, I don't know how long this paste site keeps pastes

"Posts expire after 24 hours." [rafb.net]

Re:What exactly was wrong with... Compiling! (0)

Anonymous Coward | more than 11 years ago | (#6771441)

The problem normally is simply compiling the damn module on your distro, wrong version of compiler or libraries or similar.

But in that case, we got ActivePerl,
if only they had all the packages working fine:

http://www.activeperl.com/Products/Download/Down lo ad.plex?id=ActivePerl

Re:What exactly was wrong with... (0)

Anonymous Coward | more than 11 years ago | (#6771502)

>perl -MCPAN -e 'install SomePerlModule'?

>It would get compiled for your system, warning you >and/or downloading all the required dependencies.

and hoseing your system every once and a while! when i was installing some cgi modules that way once it installed a new version of perl and somehow took out gnucash. everything was okay when i uninstalled perl and the other modules it installed then reinstalled them useing rpm. if your useing redhat use rpm, if debian use dpkg, and if you want depandancies handled use apt-get (available for both rpm and deb)

Re:What exactly was wrong with... (4, Insightful)

joe_fish (6037) | more than 11 years ago | (#6771526)

From having fought to get Bugzilla installed for about 2 days, most of the time being spent using -MCPAN can say with feeling - everything.

No uninstall.

It is yet another package system to learn

I didn't work without quite a bit of hacking (but perhaps you can blame Solaris for this)

It isn't exactly a logical syntax, compare perl -MCPAN -e 'install "Foo::Bar"' with apt-get install foo-bar

And I want the dependency system to work with my systems dependency system, and not in a parallel universe.

The Java-RPM system over at JPackage.org is good and useful, I hope this will be similarly useful.

Perl programmers can (and probably will) carry on using cpan, the rest of us can have an easier life when red-carpet or apt-get just does the right thing.

Re:What exactly was wrong with... (1)

timeOday (582209) | more than 11 years ago | (#6771549)

Because normally the user doesn't know or care that they want 'SomePerlModule' in the first place, they're just trying to install a package that depends on some .pm file with no obvious relation to the name of the module that provides it.

Re:What exactly was wrong with... (1)

Dom2 (838) | more than 11 years ago | (#6771566)

The trouble with perl -MCPAN is not only that it won't let you uninstall easily (as somebody else pointed out) but also that it won't let you install a specific version.

I'd really like to have a bundle file list version numbers so that when I install the bundle it doesn't fetch the latest version of everything on the planet. Yes, I know it's documented as doing this. But check the source. It's not implemented. EVery time you use a bundle file, you get the latest version of everything which is not always what you want.

-Dom

Existing RPM's (2, Interesting)

rf0 (159958) | more than 11 years ago | (#6771300)

OK Excuse me for being stupid but how is this any different from existing p5-Foo-Bar.rpm?

Rus

100 SERIES (1)

Magic Thread (692357) | more than 11 years ago | (#6771378)

This made the front page??? (0, Flamebait)

Anonymous Coward | more than 11 years ago | (#6771303)

Christ!

Re:This made the front page??? (0)

Anonymous Coward | more than 11 years ago | (#6771385)

Seconded. I didn't understand a word of it.

CPAN installs dependencies on the fly (1)

Vyce (697152) | more than 11 years ago | (#6771307)

Thus making it already a superior way to install Perl modules. Not to rain on a parade and this may be useful for systems where there is no CPAN (can't imagine WHY though), but where is the benefit of this over CPAN? Perhaps this will make it easy to deploy with no network connection? I'm just lost here.

Re:CPAN installs dependencies on the fly (3, Interesting)

eln (21727) | more than 11 years ago | (#6771326)

Except this thing requires a network connection too! And CPAN, IIRC, is a standard part of Perl, so if you don't have CPAN, then you don't have Perl, and thus have no use for CPAN.

In the FAQ, it states that the reasons for doing this are 1.) cool points and 2.) to hawk his book (okay he doesn't say that in as many words). Plus, it's written as a shell script, because shell scripts are portable. There is no explanation given as to why he couldn't have written it in Perl, since any system that would have any use for it at all would have Perl installed.

So, basically, he's taking the awesome resource that is CPAN, making it less useful, less portable (RedHat only), more obtuse, and more prone to error (only "around 90%" of the modules work right). Yah, this seems like a really great idea to me.

Re:CPAN installs dependencies on the fly (2, Interesting)

Kymermosst (33885) | more than 11 years ago | (#6771376)

(RedHat only)

Oh, only RedHat uses RPM? I thought SuSE and Mandrake, as well as a few others did as well. Shows what I know.

Seriously, though. I use CPAN myself, but CPAN doesn't update the RPM database with dependency & file information and such. What would be a good solution is an optional extension to the CPAN module that allowed it to place files in the RPM database.

why? (1)

jenkin sear (28765) | more than 11 years ago | (#6771315)

OK, so this is predicated on the idea that RPM is a better package manager than CPAN...and that your perl setup is pretty much identical to redhat's. Since many (if not most) perl modules don't have c extensions, a binary distribution isn't really that useful, is it? I mean, perl -MCPAN -e shell; install foo works pretty well, and will download and install dependencies for you.

I guess I'm thick or something, what am I missing here? What's the point?

Need the reverse of this (4, Insightful)

Julian Morrison (5575) | more than 11 years ago | (#6771316)

I use Mandrake and it is So Bloody Annoying to be asked by RPM to install perl module RPMs that I already installed (or updated) via "perl -MCPAN -eshell".

Not that this is really this guy's problem, but if anyone from Mandrake is reading, please take note. Either there needs to be some magic added to RPM so it treats perl modules as installed RPMs - or else, the dependency checks need to be able to look for the presence of actual modules.

Having to use --nodeps is both annoying and dangerous.

Re:Need the reverse of this (0)

Anonymous Coward | more than 11 years ago | (#6771336)

Thank you for recognizing that as a limitation of the RPM system and not of Perl or CPAN. A good package management system should be able to at least detect if it *thinks* the software has been installed, even if the software is not managed by the package manager. To do otherwise is just laziness.

Re:Need the reverse of this (1)

GigsVT (208848) | more than 11 years ago | (#6771379)

And how exactly is it supposed to do that? Short of downloading the RPM that provides the dep to see what it contains, there's really no way to tell.

I think the real solution is to make it easy to package your own packages, something like checkinstall does, but without having to guess what the "whatprovides" should say.

Re:Need the reverse of this (1)

Arandir (19206) | more than 11 years ago | (#6771413)

And how exactly is it supposed to do that?

The same way most non-RPM package managers do it. Duh!

You base your dependencies upon the contents of other packages, and not the names of the other packages. You make the package dependent upon the presence of libfoo.so.1 and not libfoo-1.3ar78.rpm.

Re:Need the reverse of this (1)

womby (30405) | more than 11 years ago | (#6771443)

the reason I stopped using RPM's in the first place was because they listed individual files as there dependencies

at last the package managers start doing the right thing and listing packages instead of there contents and you jump in and say duh don't do that

the worst thing about rpm in the old days was installing a package and having the message
depends on libfoo.so.1
then hunting through the rpm files guessing which one might satisfy that dependency
could it be foolib-1.3.rpm, libfoo-1.3.rpm, fooheaders-1.3.rpm

next time you want to jump around with your opinions try and remember your history

Re:Need the reverse of this (1)

GigsVT (208848) | more than 11 years ago | (#6771503)

You make the package dependent upon the presence of libfoo.so.1 and not libfoo-1.3ar78.rpm.

That's the way RPM works.

Re:Need the reverse of this (1)

cowbutt (21077) | more than 11 years ago | (#6771585)

You base your dependencies upon the contents of other packages, and not the names of the other packages. You make the package dependent upon the presence of libfoo.so.1 and not libfoo-1.3ar78.rpm.

The problem is that if you're distributing packages using such dependencies, there'll be a crowd of people asking you which package libfoo.so.1 comes from. Explicit package dependencies (e.g libfoo >1.3ar78) should allow most people to resolve the dependencies, and also improves the efficiency of automatic tools.

--

Re:Need the reverse of this (2, Insightful)

nzkoz (139612) | more than 11 years ago | (#6771383)

This is the reason for the RPMPan project. You'll be able to install the modules as RPMs in the first place, and software that is not in CPAN will be able to list them as dependencies.

Sounds like a solution to your problem.

Alternatively, there's always --nodeps if you're sure.

Don't want to (3, Informative)

Julian Morrison (5575) | more than 11 years ago | (#6771426)

I like the CPAN shell interface.

- it lets me search, and read the module descriptions (assuming the lazy sod module creator has written one).

- it lets me check what's out-of-date with a single command ("r"). It automatically keeps in sync with CPAN's module repository. It even updates itself live (install Bundle::CPAN; reload cpan).

- it doesn't merely install binaries, it runs the compile (so the result is guaranteed to work with my libs, or at least complain sensibly) and often asks for config options.

- it already does all the dependency stuff that RPM could do, and it does it cleaner and better and in pure perl. It detects actual dependencies rather than merely advertised ones. It can fetch the required modules and install them, without needing to ask.

- it does all this from a friendly unified command line app that I can run remotely over SSH on a co-lo server.

- it's in every install of perl (well, Perl-for-Windows is a special case, but that's nothing new).

Re:Don't want to (1)

nzkoz (139612) | more than 11 years ago | (#6771440)

So do I. I use it all the time. However somone who just wants to apt-get or yum the latest bugzilla shouldn't have to.

Re:Need the reverse of this (1)

GigsVT (208848) | more than 11 years ago | (#6771389)

Then isn't this exactly what you want? If you use these RPMs, then you won't have that problem.

Hey now... (-1, Flamebait)

soliaus (626912) | more than 11 years ago | (#6771323)

...where are my .debs' damnit?

CPAN == RPM for Perl mods (2, Insightful)

Shut the fuck up! (572058) | more than 11 years ago | (#6771325)

CPAN makes it so easy to install perl modules. Why do we need rpms?

Re:CPAN == RPM for Perl mods (5, Insightful)

akedia (665196) | more than 11 years ago | (#6771341)

There are some cases where a strictly "binary-only" system would be wanted. It is possible to build RedHat servers without GCC and stripped-down C libraries for various reasons, such as really small hard drive, or security (kinda hard for users to compile rootkits if there's no C compilier available).

CPAN builds the Perl modules in the same way you would on a source-based distro. It downloads the tarball, unzips it, does a
./configure
, checks for dependencies, then does a
make
and
make install
. RPMS don't require compiliation, and for systems lacking a C compilier, or systems with many Perl modules to install, this can be very useful. Try to imagine downloading and compiling the entire CPAN archive. It would take a week even on a fast system. Let the developers build it on something massively distributed and release an RPM that takes a few minutes to install.

Re:CPAN == RPM for Perl mods (1)

finkployd (12902) | more than 11 years ago | (#6771504)

Perhaps in case you want to uninstall a module. Go ahead, show me how CPAN does that :)

Finkployd

It solves a problem (5, Insightful)

cspenn (689387) | more than 11 years ago | (#6771329)

I see a lot of posts asking "Why" since perl -MCPAN -e shell is about as straightforward as it can get.

Obviously, it was created to scratch an itch, so cut the guy some slack. If you don't like it, don't install it. For him, and maybe for others who are new to it all and are just comfortable with one tool, it solves a problem.

Chris
http://www.studentplatinum.com [studentplatinum.com]

Re:It solves a problem (0)

Anonymous Coward | more than 11 years ago | (#6771338)

What EVERYONE is asking though is WHAT PROBLEM? That someone doesn't know about the CPAN module?
This sounds like something that will lead the already blind astray and end up only doing harm.

Re:It solves a problem (0)

Anonymous Coward | more than 11 years ago | (#6771343)

Sure, he can waste his time on useless software all he wants, but why is it on Slashdot? By these standards, I should be able to have any useless shit software i write advertised for free on Slashdot.

great (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#6771332)

take borked CPAN and couple it with the shittiest
package management system ever made

excellent

please smash my testes in joy

Good idea.. (2, Insightful)

vikku (79699) | more than 11 years ago | (#6771333)

I think this is what RedHat and Mandrake users would really like, the trick is probably in keeping all the RPMs up to date. Hope that there is a system that automatically creates RPMs from perl's CPAN module. then all one has to do is "perl -MCPAN -i " and this would download, compile, make a package and install. It would even better to make it package manager independent and add .deb support as well.

BSDPAN (4, Informative)

Moridineas (213502) | more than 11 years ago | (#6771342)

Already like this on FreeBSD systems. Called BSDPAN. Perl can be installed through the ports tree, and upgraded as easily.

Re:BSDPAN (0)

Anonymous Coward | more than 11 years ago | (#6771353)

The BSD ports tree is the most obtuse and useless package management system on the face of the Earth. Why would we want to replace CPAN with it?

Re:BSDPAN (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#6771354)

Fact: *BSD is dying

It is common knowledge that *BSD is dying, that ever hapless *BSD is mired in an irrecoverable and mortifying tangle of fatal trouble. It is perhaps anybody's guess as to which *BSD is the worst off of an admittedly suffering *BSD community. The numbers continue to decline for *BSD but FreeBSD may be hurting the most. Look at the numbers. The loss of user base for FreeBSD continues in a head spinning downward spiral.

OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of BSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.

All major marketing surveys show that *BSD has steadily declined in market share. *BSD is extremely sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among hobbyist dilettante dabblers. In truth, for all practical purposes *BSD is already dead. It is a dead man walking.

Fact: *BSD is dying

Re:BSDPAN (0)

Anonymous Coward | more than 11 years ago | (#6771583)

What is BSDPAN? I just go to the ports directory and type make install .. ?

I = Newb ... find RPM = Good .... usually (2, Funny)

skogs (628589) | more than 11 years ago | (#6771352)

I would definitely consider myself a newb to linux. been playing with it for a few months on and off. Can install them all and get them all working fully now. I can set up my webserver and link up my little homebrew website...I can serve email to myself.

I'll be honest. I am much more confident with the RPM package manager than the CPAN command you all are saying is so wonderful. Perhaps if I read an instruction book or something...but I don't generally program, so I don't have those books laying around.

I think its a good idea for newbs that can play around with the scripts and hopefully find something that works. Right now I'm working on learning PHP...but am obviously not competent on it yet.

It may be redundant for most of you well learned folks...but then so is that damn gui. I bet you all wish the gui didn't load either...since it is so redundant. :)

Re:I = Newb ... find RPM = Good .... usually (1)

gears5665 (699068) | more than 11 years ago | (#6771393)

Well, Linux has a great deal of separate functionality that you need to learn the ins and out of. Perl's CPAN is just another one to learn. The process of constantly learning is training that is invaluable. Once you've used apt, or emerge, or portage you end up scratching your head anytime someone mentions using rpm. Perl's CPAN isn't difficult but I imagine the fact that these RPMS are binary versions are what make them good...less waiting for the IT professional with a Job to do.

Re:I = Newb ... find RPM = Good .... usually (1)

skogs (628589) | more than 11 years ago | (#6771414)

yeah

I suck.

must learn more.

Honestly, I know my ins and outs with microshaft, can even realize some of the tools for admin in linux are FAR superior and EASIER to use...and free...but that doesn't mean that I know about ALL the Linux tools either.

I think this is a valuable tool for those of us out there that don't exactly have a 'full toolbox' like the rest of you. :)

WARNING: BAD ANALOGY TO FOLLOW:

Real carpenters and working men may have several hammers that they use on different things, but the starting 18 year old kid...yeah, he just buys the middle range hammer at the hardware store and beats the s#@t out of everything with it.

Already Done in Debian (2, Informative)

EconomyGuy (179008) | more than 11 years ago | (#6771358)

And its great! The best part is that .debs can specify dependencies on perl modules, which can then be met via apt. This has the added benefit of keeping all files under the control of the package manager... instead of floating around in limbo.

Of course, some of the more obscure modules never get packaged... so if this RPM database proves succesful, perhaps Debian could look into automating the package of all the smaller, less used modules.

Re:Already Done in Debian (0)

Anonymous Coward | more than 11 years ago | (#6771387)

Economy Guy writes,
. . . so if this RPM database proves succesful, perhaps Debian could look into automating the package of all the smaller, less used modules.
Hey big guy, don't want to burst your bubble but maybe Debian should first catch up with the rest of the Linux world instead of being 3 years behind the times. Priorities, son, priorities. Take care of the basics first.

Re:Already Done in Debian (1)

EconomyGuy (179008) | more than 11 years ago | (#6771469)

That's ridiculous AC... Debian is hardly 3 years behind anything. But, if your talking about things like X, where we are a whole minor version release behind, you might want to ask what the fine folks running Mips or SPARC think of Debian. Its thanks to the folks on the Debian X-Strike Force Team that X packages even exist for those architectures. Its not easy supporting 11+ archs, but the Debian Developers have taken up the task and do so very well!

Perhaps the priorities of our community are more important to us than your priorities?

Re:Already Done in Debian (0)

Anonymous Coward | more than 11 years ago | (#6771511)

Not to burst your bubble or anything, but Debian is light years ahead the other distros when it comes to managing servers. You can keep your kewl desktops and funky apps. I'll keep my stable, relatively secure (thanks to how fast & easy the security patches are to apply, amongst other things) and almost effortless to manage Debian systems. No other Linux (not that Debian is limited to one kernel) is going to come into contact with the hard disks on my servers.

Even better in Debian (3, Informative)

addikt10 (461932) | more than 11 years ago | (#6771425)

Using dh-make-perl, you can automatically grab the latest source for any module on CPAN that isn't already included in the Debian distribution, and make a deb package for it, trivially managing future updates and installation.

Mmmmmm, Debian

Re:Even better in Debian (1)

EconomyGuy (179008) | more than 11 years ago | (#6771458)

That's so cool... I had no idea. Is there anything this distribution can't do?

Imagine a... (1, Funny)

Anonymous Coward | more than 11 years ago | (#6771361)

Never Mind

you forgot the magic (1)

Magic Thread (692357) | more than 11 years ago | (#6771373)

need SCO fix (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#6771407)

need SCO fix.. nausea. dying.. pls. press release.. cant breath

Perl on Debian (2, Insightful)

penguin7of9 (697383) | more than 11 years ago | (#6771434)

Perl packages have been packaged as Debian packages for quite some time--the package and all dependencies are automatically downloaded and they are automatically kept updated.

How is this different from Debian? (2, Insightful)

Ramses0 (63476) | more than 11 years ago | (#6771454)

I'm a little bit confused as to how this is different from Debian's handling of Perl modules? Most any perl package (ie: "Date::Manip") is available as: "lib-perl", like "libdate-manip-perl".

Since they're Debian packages, you get full dependency upgrades, security updates (ie, for CGI.pm) mostly for free, although I'm guessing you're not going to get all the newest / latest / minor / crappy modules. Is that the only advantage?

--Robert

CPAN blows chunks (2, Funny)

Anonymous Coward | more than 11 years ago | (#6771471)

CPAN is banned from the servers I manage, because it likes to sometimes install shit into /usr and overwrite the OS's packaged perl libs. Bear in mind that this is after having edited the config file and pointing to /usr/local as the path to install shit into. Some modules install ok, but others just like to do whatever they want (as opposed to whatever you want). I've made it a rule that nobody with root access is to ever use CPAN to install anything (or else they get to clean up the fucking mess). Since these are all Debian servers, a lot of stuff is availabled in packaged format already, and those that aren't can be easily packaged thanks to dh-make-perl (it's so simple to use, there is no excuse not to.) And anyway, a lot of people already know CPAN sucks, which is why there exists CPAN++, but it's still in developement, or so was last I heard.
Of course, if it's just some user installing modules in his home dir, then CPAN works alright... Otherwise, caveat emptor!

Re:CPAN blows chunks (0)

Anonymous Coward | more than 11 years ago | (#6771500)

it sounds like you are an incompetent admin, sir

yes .. that is exactly what it sounds like :)

and you are

Good idea! (4, Insightful)

Daniel Quinlan (153105) | more than 11 years ago | (#6771476)

A lot of people seem to be really missing the point of this idea and seem to be making what I would call the "waaah! you can't be a real perl hacker if you like this idea" response.

First, a number of Perl packages already ship in RPM format and are distributed with Red Hat and other RPM-based distributions. This will integrate much more nicely and if package names are chosen well, it will avoid conflicts between CPAN-installed packages and RPM-installed packages. I myself use Debian and always use the Debian package instead of CPAN if it's available. It's easier, it's faster, and (in the case of Debian) you get various fixes that might not have made it into the upstream.

Once you're using some packages for Perl stuff, you might as well try to get everything in the distribution package format. In addition, I think the more appropriate question is why it's taken so long for someone to think of and then implement this idea. Why on earth would you want to use more than one package management system on your box, especially when CPAN is just for Perl packages. Using CPAN when RPM packages are available might even be silly (provided the packages are well-constructed, I don't know that they will be).

Plus, the truth is, CPAN is cool and all, but it's not all that great. The usage is bizarre and if an average user isn't a Perl person, then why should they need to learn perl to install some perl-based package that depends on some CPAN modules? CPAN also is just plain inferior to RPM and .deb when it comes to installation, deinstallation, configuration mangagement, upgrades, and just about everything else.

Now, I just hope they decide to do the same for Debian packages. (Debian provides quite a few already, but more is better.)

Perl Modules on FreeBSD (2, Informative)

Anonymous Coward | more than 11 years ago | (#6771496)

In 5.1-RELEASE at least, the CPAN module is integrated with the FreeBSD package system so that when you install a module via -MCPAN, it also registers in the package database. There are quite a few modules in the ports tree, but it seems easier simply to get the most up-to-date modules off of CPAN and then use pkg_* to deal with uninstalling modules and whatnot. Generating nightly RPMs of the entire CPAN tree seems like a fair amount of overhead. Are there enough uses for this to warrant it?

perls of wisdom (1)

ratfynk (456467) | more than 11 years ago | (#6771537)

wrapped up in an installer that R eads P rogrammers M inds. HOW WONDERFULLY SUBLIME

Make DAMN sure its STABLE before release! (0)

Anonymous Coward | more than 11 years ago | (#6771542)

I can see it now, "oops, one simple bug shut down the whole internet via a perl module RPM"

Good (0)

Anonymous Coward | more than 11 years ago | (#6771546)

It's so hard to keep track of where all those freakin' perl modules end up, with all the site_perl and vendor_perl and 5.8.0 and three or four different places where the aforementioned directories are.

How to do this in Debian! (2, Informative)

GoRK (10018) | more than 11 years ago | (#6771604)

Debian has (for quite a number of years, anyway) had the ability to generate a debian package from CPAN souces with a very very very minimal effort.

Here's how to do it in three easy steps:

Step 1: Go to CPAN and figure out what you want.

Step 2: dh-make-perl --cpan --build --install

Step 3: There is no step three!

~GoRK

Re:How to do this in Debian! (1)

GoRK (10018) | more than 11 years ago | (#6771609)

Slashdot ate my step 2. Here goes:

Step 2: dh-make-perl --cpan <Module> --build --install

Oh wow (1)

mcc (14761) | more than 11 years ago | (#6771631)

It's like, let's take the two package management systems I hate the MOST and combine them.

Uggh..
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>