Andreas Barth <[email protected]> writes: > * Goswin von Brederlow ([email protected]) [090810 00:17]: >> https://wiki.ubuntu.com/MultiarchSpec#Filesystem layout >> >> I believe wine is the first package that is experimenting with using >> that. > > I belive wine is rather totally broken as of now: > a...@ries:~$ dpkg-deb --contents > pool/main/w/wine/libwine-nas_1.1.24-2_i386.deb > drwxr-xr-x root/root 0 2009-08-09 09:05 ./ > drwxr-xr-x root/root 0 2009-08-09 09:05 ./usr/ > drwxr-xr-x root/root 0 2009-08-09 09:05 ./usr/share/ > drwxr-xr-x root/root 0 2009-08-09 09:05 ./usr/share/doc/ > drwxr-xr-x root/root 0 2009-08-09 09:05 ./usr/share/doc/libwine/ > lrwxrwxrwx root/root 0 2009-08-09 09:05 ./usr/share/doc/libwine-nas > -> libwine > a...@ries:~$ > > >> I want to be clear here. The plan I gave is the transition plan from >> ia32-apt-get to multiarch. > > I think you missed the bit about "accepted by the community at large". > Changes like multiarch cannot just be driven by a single person > without any buyin.
I'm not driving multiarch with ia32-libs-tools nor did I present a plan how to implement multiarch in Debian. The Release Team has declared multiarch a goal for Squeeze, not me. Not having a plan to transition to multiarch was given as a reason against it. I just refuted that by outlined how ia32-libs-tools would follow whatever plan the project decides to implement the Ubuntu multiarch proposal and that there will be no holdups due to ia32-libs-tools. On the other hand, if Debian does not implement the Ubuntu multiarch proposal then potentially causing problems for the proposal can hardly be grounds for removing ia32-libs-tools. So multiarch or no multiarch in Debian ia32-libs-tools will play game, go along, transition smoothly, not hinder anything. That is all I ment to show. >> > http://lists.debian.org/debian-devel/2009/07/msg00060.html - >> > ftp-masters on removal >> >> Also about the dpkg/apt diversion and taking over ia32-libs. Or so I >> assumed. That mail was following the discussion on irc [...] > > I'm not going to say now that I think that the ftp-team had the best > strategy for communicating that decision. That doesn't make the > decision wrong however. I'm definitly not going to override a decision > just for the reason that the way it was taken wasn't optimal, > especially if after careful review the decision seems to be the right > one. While that greatly annoys me too I didn't ask you to overturn it for lack of communicating. Firstly I asked you to find out the reason behind the decision since I couldn't get an answere. So far I have only seen one reason stated clearly: Might hinder transition to multiarch. I think I have shown how I intend to handle that transition in ia32-libs-tools whenever and however Debian will do it. So far nobody has pointed out flaws in that plan. So I wonder what other reasons for removing ia32-libs-tools there are. Or are there flaws in my plan? Because if that was the only reason and I've shown it to be baseless then you would have grounds to overturn the decision. MfG Goswin -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
