On Fri, 2005-02-25 at 08:53 -0600, Chris Adams wrote: >Once upon a time, David Woodhouse <dwmw2@xxxxxxxxxxxxx> said: >> If it's built against >> versions of shared libraries which are no longer present, then I believe >> the installer will have removed the old version of those libraries and >> will have left the package in question broken. > >Do you have evidence to back that up? Does anaconda somehow disable the >normal dependency checking? Normally, rpm would refuse to remove a >library that is still required by another installed RPM. > >I can see that you would be unable to upgrade if: > >- existing RPM xyzzy required libfoo.so.1 >- existing RPM libfoo-1.0 provides libfoo.so.1 >- RPM xyzzy was moved from Core to Extras (so unavailable for FC4 install) >- new RPM libfoo-2.0 provides libfoo.so.2 >- new RPM system-config-bar requires libfoo.so.2 and is in the default install Unfortunately, most library packages in Fedora aren't packaged nearly so intelligently. Worse, many library packages aren't even split from applications (curl utility vs libcurl, for example - both come in a single package) so all sorts of unfortunate situations arise when you use a package not in Core (or Extras, once that's fully integrated) that depends on a library that gets upgraded in the next release. And, unfortunately, real people generally do need or want a package or three not supplied by Fedora, so these issues pop up regularly. Every bug I've filed pointing out the problem caused by poorly packaged libraries gets closed with a message that's the equivalent of, "This isn't worth our time, you must eat babies if you use packages outside of Core, and there's no real advantage at all to not breaking stuff, so go away." Kind of frustrating, to say the least... > >If there isn't a compat-libfoo that provides libfoo.so.1, you would be >stuck. The question is: what would anaconda do in that case? Would it Or what happens in FC+2 where compat-libfoo doesn't provide libfoo.so.1 anymore, but now only provides libfoo.so.2? The entire compat-* is so incredibly brain damaged and poorly conceived that I am honestly shocked it's actually lived this long. If you're going to have multiple packages provide multiple versions of a library, name the package according to the version it supplies, so you can actually have *many* versions of a library installed (if you need it) without needing to do manual rpm -i foo-hackery that tends to break all sorts of useful things (like upgrades). >abort installation because dependencies cannot be satisfied, or would it >attempt to upgrade anyway (and break either RPM xyzzy or RPM >system-config-bar)? > >-- >Chris Adams <cmadams@xxxxxxxxxx> >Systems and Network Administrator - HiWAAY Internet Services >I don't speak for anybody but myself - that's enough trouble. > -- Sean Middleditch <elanthis@xxxxxxxxxxxxxxx>
