> I certainly prefer NOT doing any ugly stuff with dpkg. > "apt-get dist-upgrade" will uninstall packages that havn't been updated > to the new c++ yet, which certainly is worth a bug report on these > packages... Oops, I meant upgrade not dist-upgrade. dist-upgrade is bad :) > That is exactly the PRO of a good dependency management... > Instead of hacking some ugly stuff into dpkg, which is likely to break > more stuff, and adding a wrapper to _hundrets_ of applications certainly > is ugly... But the wrapper is only required for G++ v2 packages, that should hopefully be a very small number. > hacking the dynamic linker certainly is better than that... This only allows to avoid creating wrappers but doesn't avoid the problem that two libraries can't have the same filename. Something (dpkg) must move one of them. > ANY such hack is more likely do break than the dependency system (which > will just keep a few packages in an "uninstallable" state for sid, > people could always get the latest package from sarge...) Aren't the G++ 3.2 packages going to be moved into sarge? Even if you do so when the transition is complete, there will still be non-Debian G++ v2 packages installed on users' machines. > The change from libpng2 -> libpng3 with gtk2 was FINE, imho. It worked > like a charm... I waited until the list of packages which would be > deinstalled by that move contained and switched then... i lost just two > or three apps i had installed, so what... (mostly i lost > mozilla-snapshot and galeon-snapshot which i built myself ;) > And if that gcc -> 3.2 move takes a month - well, i can live a months > with the software versions i have installed right now. I don't need the > bleeding edge for any price. The dependencies should help me know the > price i had to pay... ;) The change from libpng2 to libpng3 is a total disaster like this one. Fortunately it might be easier to solve (it looks like relinking GTK with -Bsymbolic might do the trick, but I'm also not an expert of dynamic linking). What I especially don't like is the concept that GTK+, that doesn't use any png structure in its interface, can dictate what a program using it does with libpng. This concept is inherently totally absurd and broken and _anything_ is better than allowing something as stupid as this. And I'm surprised that this isn't obvious and that this transition was not stopped by anyone. > But people will need to learn the difference between apt-get upgrade and > apt-get dist-upgrade... i guess we'll get dozens of these bug reports > while doing the move... > > BUT: > What about preparing for future instances of this problem? > Could we maybe have all new libs in /usr/lib/libc6/gcc3.2/ > so if this occurs again, it will easier be solved? > (hmm... i don't like these paths, either... but some stuff like this > should probably be done...) But this API is supposed to be the final one, isn't it? :) And if it changes, the problem can be fixed in the same way as this one, or better if an unstrippable ABI tag is put in G++ compiled objects. Anyway, putting v3 packages in a separate directory still requires to modify /etc/ld.so.conf and create wrappers for v2 packages. And we still have the problem of external packages that don't obey the rule of the gcc-3.2 directory.
Attachment:
signature.asc
Description: This is a digitally signed message part