> > > > 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. > > > > > > No, they are not, as long as there are dependency problems, and as long > > > as we keep a bug "G++ 3.2 transition incomplete" open... > > > There are -nice- and -tested- methods to do such things. > > That works as long as user only install Debian packages, but obviously > > doesn't work for non-Debian ones. > > If they use proper dependencies it works just fine. They can't be > installed unless they fit to the system. That is the ONLY correct thing. Correctly installing them is much better than declaring them uninstallable.
> If they install stuff by hand, your automatic wrapper generation and > library moving will not help either. > If you want to fix alienated rpm's - do that in alien. They help if I install packages that want to put libraries in the wrong directory, including all existing library packages that don't know about /usr/lib/g++-2. > > > No, the transition worked fine. The disaster is not the way Debian gtk2 > > > migrated, but the library itself. > > No, it is in the fact the neither the library authors nor Debian fixed > > the problem. > > Which is completely separte from the correct way to package these > things, and that is what we are talking about... the libpng issues > cannot be solved by a dpkg hack! No, dpkg hacks solve the problem of two files trying to be in the same place. > They did not solve the libpng problem (which is not to be solved by > debian, but by upstream and all distributions _together_) but they set > the dependencies correctly, so packages don't break. Without a hack. > Which is great. Debian can solve it by releasing a version of GTK+ 2.0 that works with binaries that use libpng2 and also with ones that use libpng3 or, if that is not possible, at least releasing a distribution (i.e. dynamic loader + GTK+) that achieves this goal. > We don't have any v3 binaries yet. So where is the problem? > The maintainers could include proper wrappers for them. that is better > than doing some automatic wrappers... What?! Including duplicated crap in *lots* of packages is better than a central fix? How about non-Debian packages? You can see the result of this mindset in the /usr/doc transition. If rather than having packages/debhelper do the transition themselves, dpkg was modified, it would have been done in at most a week. The work required to create packages should be reduced, not increased. > You could even use alternatives to switch from default-is-v2 to > default-is-v3 and remove all wrappers at once, when you modified your > library paths... No hack needed for that either. And how do you easily run from the command line both a v2 ABI program and a v3 ABI one without needing to know about the issue? > Don't take stuff unnecessarily out of control of maintainers. Many apps > use wrappers already, why force them to use another wrapper. You'll > break LOTs of things. For example mozilla does use some wrapper to set > LD_LIBRARY_PATH correctly... your automatic wrapper generation will > maybe not work, and if it does it's definitely inferior to having the > maintainer do a proper wrapper himself... Yes, you are right. Modifying the dynamic linker is much better.
signature.asc
Description: This is a digitally signed message part
