Danny Howard wrote:
Ah, okay, I have an answer here ...
http://dag.wieers.com/home-made/apt/FAQ.php#B5
Summary:
Edit /etc/sysconfig/rhn/sources and add:
yum dag http://apt.sw.be/redhat/el3/en/i386/dag
up2date <package>
Thanks, guys.
Hey, that's really good stuff. A related question, from a developer
who's masquerading as a sysadmin:
I presume up2date still maintains the dependency relationships if I
install from a third-party repository like that. But what's the best
practice for replacing RPM software with source-built versions? There
will always be some RHEL packages that become out of date, and yet
aren't replaced by third-party repositories. And from what I've read,
installing Fedora packages on RHEL is a hit-or-miss proposition.
For instance, RHEL4 uses GTK 2.4. I've got some apps that need new
features in GTK2.6 or 2.8, and these aren't in the above-mentioned
dag/rpmforge repository, so I need to build them myself. Ditto
subversion, httpd, etc. Over time, the configuration is bound to
deviate more and more from stock.
In the past, on my home Mandrake machine, I've always just installed the
source versions right over the top of the RPMs. But obviously that gets
you into trouble over time, as up2date tries to install security patches
of the base versions over your now-home-built libraries. This could
possibly explain why nothing works on my Mandrake box anymore.
Yet I can't easily uninstall gtk, because it's got a zillion packages
that depend on it. And yet I'm not really uninstalling it; I just want
to upgrade it.
For each source-built item, I could figure out the corresponding Red Hat
package, and add to the up2date skip-list, but that seems to get ignored
at the RHN web site, and possibly some other place that I now forget.
And that's not totally useful, because it might lead to an apparent
dependency that doesn't exist; some future (third-party) rpm might
depend on GTK 2.6, which I have, but which up2date doesn't know I have!
Or I could uninstall it --nodeps, but again, that messes up the
dependency tracking. Is there a better way?
Jay Levitt
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
