Perl Modules as RPM Packages 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."
This discussion has been archived.
No new comments can be posted.
Perl Modules as RPM Packages
Related Links Top of the: day, week, month.
The 11 is for people with the pride of a 10 and the pocketbook of an 8. -- R.B. Greenberg [referring to PDPs?]
perl with RPM lovin' ? (Score:5, Funny)
# 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' ? (Score:5, Funny)
# 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' ? (Score:5, Insightful)
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.
--
Re:perl with RPM lovin' ? (Score:2)
See, this is why I never liked package management for other than the base system (like, say, how Slackware does it). Sooner or later I'm going to need some version of some program that's not supported by the package maintainers of my OS, and then I'm off 'rol
Re:perl with RPM lovin' ? (Score:2, Interesting)
If the basic packaging system was used by developers too this would not be a problem.
Of course, establing one standard will take some time. Especially since different distros package things in slightly different ways.
Re:perl with RPM lovin' ? (Score:2)
Personally, I find managing all my packages with RPM useful (things like rpm -e, rpm --verify, rpm --checksig, rpm -qif `which foo` - I have 1321 packages on my workstation which I would hate to have to m
Re:perl with RPM lovin' ? (Score:2)
The following packages will be installed:
myperl, libsomeshit, libXML, mozilla
Need to get n MB of archives.
Do you want to continue? [Y/n] y
And then the packages are installed, and you live happily everafter.
Re:perl with RPM lovin' ? (Score:2)
Would be damn nice thing to have, that... but who knows whether that person even reads slashdot? Not to mention finds this specific thread, better ask by mail if you want answer
Re:perl with RPM lovin' ? (Score:5, Interesting)
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' ? (Score:5, Funny)
Re:perl with RPM lovin' ? (Score:2)
'zat better? ;-)
--
Re:perl with RPM lovin' ? (Score:2)
No. You didn't mention Gentoo or Debian.
Re:perl with RPM lovin' ? (Score:3, Funny)
> a vast conspiracy plotted jointly by the Freemasons, the Zeta
> Reticulans and the Bilderberg group.
No, you are mistaken. The Bilderberg group has nothing to do with
it. The true ringleaders are the same nameless group who also
mastermind the MVD/NSA/Bahrain connection.
Also, rpm is only their primary tool for one specific purpose
(undermining OSS). They have plenty of other tools that they
employ, to accomplish various nefarious pu
Re:perl with RPM lovin' ? (Score:2, Interesting)
package management solution than plain vanilla rpm. There are also
tools that go on top of rpm and help somewhat with this, such as
urpmi, but as yet none of the package repositories are anywhere near
as robust as the CPAN system of mirrors. I have often wished that
non-Perl packages were available via CPAN, though I certainly
understand why they're not.
-1 Troll (Score:5, Insightful)
Uh, I'd just do:
What's the problem again?Re:perl with RPM lovin' ? (Score:4, Informative)
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.
p5-Compress-Zlib-1.22
p5-DateTime-0.16
p5-Da
p5-DateTime-Format-ISO
p5-DateTime-Format-Strptime-1.0302
p5-
p5-DateTime-TimeZone-0.25
p
p5-File-Find-Rule-0.11
p
p5-Module-Build-0.19
p5-Numbe
p5-Params-Validate-0.64
p5-Pod-Es
p5-Pod-Simple-0.96
p5-Test-Builder-Te
p5-Test-Harness-2.28
p5-Test-Pod-0.95
p5-Text-Glob-0.05
p5-Text
p5-Time-Local-1.07
p5-YAML-
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? (Score:5, Insightful)
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? (Score:4, Insightful)
Re:Huh? (Score:3, Insightful)
Re:Huh? (Score:5, Informative)
Yes, it is. Check out cpan2rpm [cpan.org].
The best of both worlds - modules built locally, with rpm ease of installation and de-installation.
Re:Huh? (Score:2, Insightful)
Except that there need to be different rpms for RedHat, Mandrake, SuSE
Really, the cpan setup keeps track of its own dependencies, and gives you flippant comments like "yep, it's a nice idea to include this if you actually were to wish to use that" to boot. No rpm setup can get clos
Re:Huh? (Score:2)
Not necessarily. Perhaps a different set for each version of Perl. Perl has a pretty standard location for this type of stuff, across distros, I THINK.
> No rpm setup can get close to that.
Maybe not rpm. Apt and ebuild would do it.
Re:Huh? (Score:4, Interesting)
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? (Score:4, Informative)
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? (Score:2, Interesting)
> 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 (!)
For DBD::mysql, I think you can say no when it asks if you want to
test. mod_perl is a problem if you don't have the Apache sources
installed, and IMO the correct solution is to i
...primarily to used by perl??? (Score:2)
I've installed Apache tons of times without support for mod_perl, and let me tell you unless you are doing a LAMP installation you don't want to think about it.
Similarly, there are tons of non-perl apps that use MySQL as a backend for various reasons (usually to supplant huge flat configuration files or logs).
Not everything is webserving, man!
Re:Huh? (Score:3, Funny)
Re:Huh? (Score:5, Insightful)
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
Re:Huh? (Score:2)
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
And let me know if/when you figure that problem out. You could do some
Re:Huh? (Score:2)
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 alwa
Re:Huh? (Score:3, Interesting)
It isn't very hard to do "./configure && make install" either for normal software, yet we still haver package managers?
Why, you ask? Because we want to be able to uninstall stuff as well, because we want to have dependencies and because we want everything relating to software installation be handled by one program (apt or yum, for example).
So, not only are they converting Perl modules t
seems a little wasteful.. (Score:3, Interesting)
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... (Score:4, Insightful)
It would get compiled for your system, warning you and/or downloading all the required dependencies.
Re:What exactly was wrong with... (Score:3, Funny)
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
Re:What exactly was wrong with... (Score:2)
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
Uninstall? (Score:4, Insightful)
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? (Score:5, Informative)
[root@ocicat root]# perl -MCPANPLUS -e shell
CPANPLUS::Shell::Default -- CPAN exploration and modules installation (v0.03)
*** Please report bugs to <cpanplusbugs@lists.sourceforge.net>.
*** Using CPANPLUS::Backend v0.042. ReadLine support enabled.
CPAN Terminal> u File::ReadBackwards
Checking if source files are up to date
Retrieving
Retrieving
Retrieving
Uninstalling: File::ReadBackwards
unlinking
unlinking
unlinking
Uninstalled File::ReadBackwards successfully
All modules uninstalled successfully
CPAN Terminal>
Exiting CPANPLUS shell
[root@ocicat root]#
Re:What exactly was wrong with... (Score:5, Insightful)
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... (Score:3, Informative)
Lesson learned: never install a binary Perl package with CPAN. Go get the RPM for your distro, and hope it hasn't been EOL'd yet (trying to find RedH
Re:What exactly was wrong with... (Score:2)
Re:What exactly was wrong with... (Score:2)
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 alwa
Existing RPM's (Score:3, Interesting)
Rus
Re:Existing RPM's (Score:2)
--Joey
why? (Score:2)
I guess I'm thick or something, what am I missing here? What's the point?
Re:why? (Score:2)
This is the essential problem with make also. It is getting too hard to keep track of all the destination and dependancy differences that are happening. CPAN is a great so
Need the reverse of this (Score:5, Insightful)
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 (Score:3, Insightful)
Sounds like a solution to your problem.
Alternatively, there's always --nodeps if you're sure.
Don't want to (Score:4, Informative)
- 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 (Score:2)
Re:Need the reverse of this (Score:2)
This might be possible, but one obvious problem is what happens when those files are later removed or replaced. For example, you have fred-1.0 installed by hand and install an RPM package of jim-0.1, which depends on fred = 1.0. Well, perhaps RPM coul
Disagreed (Score:2)
Your scenario describes one stupid way of shooting yourself in the foot, but it's hardly a unique one. Other similar ones would be: uninstalling with --nodeps, overwriting an RPM with a "make install", overwriting libs with a newer version and "-ivh --force" so as to make new programs load whilst keeping older ones, etc etc.
Basically, it's a problem that won't bite newbies (becaue the
Re:Need the reverse of this (Score:2)
Let's assume I just installed relatively uknown perl module uglebugle and C library fdasgfgfa by CPAN and "make install", I didn't, of course, notify package manager about this because it has to be smart enough to deal with them itself. Now our package manager scans a file system and notices few new files, fdasgfgfa.so and uglebugle.pm, of course there's no trace of them in it's package database because they ar
Re:Need the reverse of this (Score:2)
Package manager has no idea about what files belong to which software package unless they are installed trough itself.
Should've used the damn preview...
Re:Need the reverse of this (Score:2)
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 (Score:2)
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 too
Re:Need the reverse of this (Score:2)
But in this case it's your history. I've worked with RedHat for several years and dealt with what most people would consider huge networks of machines running it. This has never really bothered me. *shrug*
Re:Need the reverse of this (Score:2)
You base the dependency on a file, but you still use a package. For example, the dependency is listed as "libfoo.so.1 | libfoo-1.3a.pkg". So when you're installing FooApp, it looks for libfoo.so.1, knowing that it is provided in libfoo-1.3a.pkg. So if the file isn't there, the package can be installed.
CPAN == RPM for Perl mods (Score:2, Insightful)
Re:CPAN == RPM for Perl mods (Score:5, Insightful)
CPAN builds the Perl modules in the same way you would on a source-based distro. It downloads the tarball, unzips it, does a , checks for dependencies, then does a and . 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: (Score:2)
Re:CPAN == RPM for Perl mods (Score:4, Informative)
Why should we have different database for perl modules than rest of the system? While we're it for perl, why not make one for c, another for c++, yet one for java, then there should be one for python, etc etc. That'd be a frickin' nightmare and best of all those wouldn't have any knowledge of each other, so if my C program depends on perl modules it wouldn't have any way of knowing if it's installed or not because it uses different package manager.
Thanks but no thanks. I want one thing to keep track of ALL software, no matter what language it's written in.
It solves a problem (Score:5, Insightful)
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]
Good idea.. (Score:2, Insightful)
BSDPAN (Score:5, Informative)
Re:BSDPAN (Score:2)
Re:BSDPAN (Score:2)
I = Newb ... find RPM = Good .... usually (Score:3, Funny)
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 (Score:2)
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 s
Re:I = Newb ... find RPM = Good .... usually (Score:2)
It took me about 6 months to move around comfortably...I've added Perl programming skills, some trivial sed stuff, and various grep and regex stuff to my toolkit over the remaining years.
A friend of mine in college who helped me learn Linux (I already had a little background in Solaris as a user) told me that if you were to graph "knowledge of the OS" on
Already Done in Debian (Score:2, Informative)
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.
Even better in Debian (Score:3, Informative)
Mmmmmm, Debian
Perl on Debian (Score:2, Insightful)
How is this different from Debian? (Score:2, Insightful)
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 (Score:2, Funny)
Good idea! (Score:5, Insightful)
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.)
Another reason it's a good idea (Score:2)
More than once I've sworn that there weren't RPM's
Perl Modules on FreeBSD (Score:2, Informative)
perls of wisdom (Score:2)
How to do this in Debian! (Score:3, Informative)
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! (Score:2)
Step 2: dh-make-perl --cpan <Module> --build --install
Oh wow (Score:2)
Uggh..
cpanflute? (Score:2)
cpanflute foo.tar.gz ; rpmbuild --rebuild foo-*.src.rpm
(mod up) (Score:2)
Anything that helps you autogenerate RPMS is useful in my mind.
Just tried this today. My results. (Score:3, Informative)
Apparantly there is a major disconnect between package dependencies and what is actually installed on a box.
I wanted to add RPC::XML to my Mandrake box, so I tried installing the rpm version. It complained about a list of about 20 failed dependencies, missing packages.
So I grabbed the tar from CPAN and did the good old make install and it mentioned that only the XML-Parser was missing.
So... would the rpm have worked if I told it to ignore dependencies, since those perl lib's were already on the box?
Just need a apt repos now :-) (Score:2)
This is great, for a while I have been using cpan2flute which comes in an RPM from freshrpms [freshrpms.net] to build my own RPMs from CPAN for my RedHat boxen, and this will save me from doing that :-)
Will there be an apt repository? I hope so :-)
Also will it be able to cope with ImageMagik -- probably the hardest Perl module to get working in my experience...
Perl Modules as RPM Packages (Score:2, Insightful)
The Perl environment is installation dependant. The location of your siteperl, the C compiler version, the location of your libs, and even the version of your compilor are encoded into the makemaker environment.
The use of RPM to install modules will require that all distributions follow a standard.
What if I wnated to install perl 5.8 on
What do I do if the RPM binary was built with incompatable paths and compilers?
Willia
Re:Perl Modules as RPM Packages (Score:2)
Bad idea.
[...]
What if I wnated to install perl 5.8 on
Then you don't want to use RPMs. But you're an exception; 99% just want to install the packages and expect it to work. Only a few hackers are going to do stuff like that.
whats the point? (Score:2)
Re:whats the point? (Score:2)
*starts doing a little dance* (Score:2)
In the past, I've had problems w/ wanting to use a module, which is dependent on 5 other modules, which is then dependent on 5 more, etc., so I end up building 10-20 RPMs for just 1 module. Which I will have to update sometime in the future...bugger! Which, when under time pressure, ge
one more reason (Score:2)
When I ship software to customer on CD, which uses some perl script they expect me to have ALL they need on this CD. Knowing their version of Redhat Linux I can pick and package appropriate CPAN RPMS and be sure that RPM package manager will take care of dependencies.
Besides (beleive it or not!) there are some computers which do not have internet connection. Some people want to be able to install per
Parallel package managers (Score:3)
- Once you use a package management system, you are locked into that system.
- If you use two (or more) different systems, one will not know about the other and you'll end up with an awful mess when you install things with similar dependencies.
- If you manually build and install some software, the package managers won't know about it and you'll end up with a mess.
Instead of using a database of some sort in the package manager, why don't the package managers "search" for the proper dependencies? I know it might take significant resources to perform such a search, but it can be narrowed down by a simple configuration file (likeOnce something like that takes place, you'll be able to download whichever package format(s) you choose at any time, and ideas like Perl Module RPMs will be a good idea.
Re:CPAN installs dependencies on the fly (Score:4, Interesting)
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 (Score:3, Interesting)
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.
Re:CPAN installs dependencies on the fly (Score:3, Insightful)
They do use different versions of perl. You could say every distribution, and every version of a distribution is different. A package made on Redhat isn't guaranteed to work on Mandrake, and vice-versa. So if this projects makes rpms for Redhat, then that's what it does.
What would be a good solution is an optional extension to the CPAN module that allowed it to place files in the RPM database.
Isn't that what
Re:CPAN installs dependencies on the fly (Score:2)
Now, that's a different statement entirely.
This really shouldn't be a problem for distributions shipping perl 5.6/5.8 when dealing with perl-only modules... but I can see the wrench when dealing with mo
Re:obligatory gentoo zealotry (Score:3, Informative)
Re:obligatory gentoo zealotry (Score:2)
Re:obligatory gentoo zealotry (Score:2, Informative)
It does not do updates - it doesn't 'sync' with anything. It's a mechanism to merge (and unmerge) anything that's available on CPAN.
Overall it's pretty sweet.. and needs exposure.
Re:obligatory gentoo zealotry (Score:2)