Hi,
I often have the problem where I need a newer version of some package X
(for some other package), but I have about 100 things depending on X.
For example, png was recently upgraded, and in order to install
anything that depends on png I first had to remove my existing png
which all of Gnome (and other things) depended on. Obviously, the "right"
thing to do is to update all the packages that depend on png, but that
would take a LONG time and seems like a waste.

Sometimes I just backup the +REQUIRED_BY file, forcefully delete the
package and install the new one - replacing the REQUIRED_BY file.  This
usually works fine when the package has only changed slightly, but is
_really_ asking for trouble.

Another alternative that I see is to install both versions of the package
in question.  Since shared libraries are normally the issue, if the
library has the same name we should be ok replacing it, otherwise we'll
end up with both versions of the library which should be fine also.  Of
course, lots of files like .h and .a files may get overwritten, but thats
ok since new programs building against that package should be using the
newer version anyway.  The only major problem I see with this approach is
that when I go to delete the old version of the package, it'll delete
files belonging to the new version, right?  And without looking closely at
the package, you have no way of knowing if some other important data files
will get clobbered breaking the old version.

Is there some tool that will install a new version of a package, and
update the packing list for the old version to not include any files that
were overwritten?  Is there any other problem with having two versions of
a package installed?  Is there any way we could specify that its ok for
certain packages to have multiple versions installed (especially for
packages like glib which even puts its header files in version-specific
directories)?

How to others deal with this situation?  Do people reall just rebuild
Gnome, etc. all the time?

Thanks,
	Rick