Ubuntu

Bug #733501
Comment #5

Comment 5 for bug 733501

Revision history for this message

Martin Pitt (pitti) wrote on 2011-03-14:

Thanks Steve for the detailled plan.

"dpkg that implements support for the final library paths", "gcc and eglibc to use the paths", and "debhelper and pkg-config patches to support multiarch" will only enable additional library search paths, and thus our current libary packages should continue to work unmodified, right? That is, with the exception of lib32ffi-dev and friends; do you know (by grepping Contents.gz or similar) that this is the complete list? The steps until here (and the transition document, of course) seem low risk to me. As you said, there might be a potential dpkg db change, but we only need to fix that for intra-natty upgraders, and it shouldn't be too difficult. I agree with Kate that I'd like to have these changes in well before beta, so that we can do the major testing rounds with the new infrastructure in place.

I don't think we are in a hurry to update the library stack by beta. We should,, upload a small set of central libraries (i. e. if something breaks, we _will_ notice), such as glib2.0, libx11, libxcb, libpcre, and libdl (all of which are required by libflashplayer.so). gtk isn't needed by flashplayer, but converting that early would be interesting because it would test the robustness with runtime loaded platform specific modules (/usr/lib/gtk-2.0/2.10.0/immodules/*.so and /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/*.so) We should then leave this in the archive for a few days, iron out the problems, and could then continue until beta-2.

Question here: Once the new debhelper is in, will library packages will be built for multiarch compatible paths by default, or does this need to be enabled in debian/rules?

Getting up to the point of flashplugin is a very laudable goal, as this is probably the #1 reason why people have ia32-libs installed. The flash player has tons of vulnerabilities, and so far people are using it with outdated libraries (which ia32-libs constantly is). So I agree that for this benefit it is worth taking some risk here.

Thanks Steve for the detailled plan.

"dpkg that implements support for the final library paths", "gcc and eglibc to use the paths", and "debhelper and pkg-config patches to support multiarch" will only enable additional library search paths, and thus our current libary packages should continue to work unmodified, right? That  is, with the exception of lib32ffi-dev and friends; do you know (by grepping Contents.gz or similar) that this is the complete list? The steps until here (and the transition document, of course) seem low risk to me. As you said, there might be a potential dpkg db change, but we only need to fix that for intra-natty upgraders, and it shouldn't be too difficult. I agree with Kate that I'd like to have these changes in well before beta, so that we can do the major testing rounds with the new infrastructure in place.

Question here: Once the new debhelper is in, will library packages will be built for multiarch compatible paths by default, or does this need to be enabled in debian/rules?

Getting up to the point of flashplugin is  a very laudable goal, as this is probably the #1 reason why people have ia32-libs installed. The flash player has tons of vulnerabilities, and so far people are using it with outdated libraries (which ia32-libs constantly is). So I agree that for this benefit it is worth taking some risk here.