[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to transition to G++ 3.2 wthout any breakage

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.
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
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

Reply to: