On Tue, 14 Dec 2004, Thomas Cameron wrote: > ----- Original Message ----- > From: "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx> > To: "RPM Package Manager" <rpm-list@xxxxxxxxxx> > Sent: Tuesday, December 14, 2004 9:21 AM > Subject: Re: how to satisfy "perl(XXX::YYY)" dependencies? > > > at this point, i understand the options and i'm going to give cpan2rpm > > a try. and, no, it's not a "pretty pissy gripe", > > Yes, it is. Mixing "installed from source" or "installed from CPAN" > software with packaged software (ala RPM) is a Bad Thing(TM). You > apparently don't understand that yet, which is cool - you're new, > you'll learn. um ... patronizing condescension really doesn't become you. but there's more to it than that. i've snipped a fair chunk of your post, but your point seems to be that, when working with an RPM-based system, you really have to restrict yourself *exclusively* to managing *all* your software through RPM, as that's the only way to remain consistent. installing from, say, source or CPAN will make a mess of the software management since there's no way rpm will know about non-rpm installed entities. superficially, that sounds reasonable, until you look at some of the standard installed RPMs. for example, consider "initscripts", and its list of requirements: ===== $ rpm -qR initscripts /bin/awk /bin/bash /bin/grep /bin/sed /bin/sh /bin/sh /bin/sh /bin/sh /bin/sh /etc/redhat-release /sbin/arping /sbin/chkconfig /sbin/fuser /sbin/ip /sbin/nash /sbin/runuser /sbin/sysctl /usr/sbin/groupadd SysVinit bash >= 2.0 ..... snip ..... ===== note how the list of dependencies doesn't include just other rpms. it specifically includes *individual* *files*, with no regard to where they came from (at least, as i read it). in short, even a stock standard, unmodified fedora core rpm-based system *already* incorporates non-rpm information in its own install process. ergo, your point is irrelevant. my main point was that it seemed wasteful for an rpm file, if it needed a particular perl module, to *demand* that that module be installed via rpm if it's already on the system. why should the process care? sure, it would be terrific if *everything* on the system was managed by rpm, but that's *already* not true, as you can see above. if an rpm file can have a dependency of a single file, it's not clear why it can't have a dependency of a perl module, as long as that module is on the system somewhere, regardless of how it got there. (this would depend, of course, on how easy it would be to check that, but the general idea seems sound. but having to, effectively, re-install numerous already-installed perl modules that are *already* on your system seems horribly inefficient.) of course, i'll admit that it would be terrific if *everything* on the system could be under the management of rpm. however, as i show above, given that that's *already* not true, it seems a bit late to try to be a purist, no? rday p.s. as i thought about it a bit more, i realized that, as you continue to configure your system, you'll naturally be adding various configuration files that weren't there in the first place. imagine, say, setting up your system as a CVS server, for which you might want to add the config file /etc/xinetd.d/cvspserver. how do you get that file onto your system? most likely, just edit it and throw it in the appropriate directory, which is what i suspect many people will do. suddenly, you have a file that's not owned by any package and not under rpm management. oops. by your logic, you've just contaminated your system with a non-rpm file. and i suspect this happens fairly frequently. so, again, it seems a bit late to try to be a purist. a perfectly typical rpm-based linux system most likely already *has* numerous files that aren't under rpm control. trying to ignore perl modules for that reason seems a bit weak. _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
