On Sun, 2002-08-18 at 17:47, Steve Langasek wrote: > On Sun, Aug 18, 2002 at 05:36:04PM +0200, Luca Barbieri wrote: > > > No because it is overcomplicated > > This isn't a problem for you, I'm doing the work (I have already managed > > to write a program to detect the ABI, a wrapper generator and patched > > dpkg to move libraries; I still have to do shlibs support and hook the > > wrapper generator to dpkg). > > If it isn't accepted, I'll just further patch dpkg and apt to ignore the > > bogus conflicts that would be added and use it locally. > > Complexity is directly proportional to bug frequency. It's a problem for > all of us when unnecessarily complex kluges are added to dpkg. Yes, this would significantly increase the chance of dpkg bugs, but that IMHO does not make this approach worse than the other one (as long as the new dpkg is tested and left in experimental for a few days before putting it on unstable). > > > and dpkg has no business making this kind > > > of on-the-fly adjustment. > > Of course it would be better to avoid having to do things like this but > > unfortunately there is simply no other solution that doesn't break > > existing G++ v2 packages. > > Of course there is. You upload new versions of the gcc 2.95 packages, > and you make the new gcc 3.2 packages conflict with the old ones. > Nothing is broken in that case. False. Users will no longer get updated version of any C++ package unless they manually remove/recompile any package depending on the old libraries which is not yet recompiled or is not in Debian. For example, how about calc.cx KDE 3.0 packages that are obviously necessary for any KDE user? I don't see any mention of GCC 3.2 on their text file so I assume that they aren't ported. Actually I think that those packages don't require any external C++ library so they may still work, but what if they required one? What would a KDE user do? Go back to the obsolete 2.2? Be no longer able to get upgraded Debian packages, that might even contain security fixes? Recompile packages on its own? Would those alternatives be better than an ugly fix limited to dpkg? And finally, if the machine is doing unattended dist-upgrades from cron with no one checking logs, not being able to get upgraded packages leads to potentially unfixed security holes. This is especially a problem if you are going to move the packages to testing and stop maintaining the old ones. Now the user has to choose between the ancient unupgraded stable or a machine that might become permanently insecure due to uninstallable packages. However it seems that Debian makes no effort to avoid this, so this probably isn't an important factor in this particular decision on the GCC 3.2 transition.
Attachment:
signature.asc
Description: This is a digitally signed message part