Steve Langasek wrote:
> As long as you're considering adding this at a new debhelper compat level, I
> think we should look at the possibility of v9 being multiarch-by-default -
> i.e., passing a multiarch default --libdir (or equivalent) to the build
> system with dh_auto_configure, adding "multiarch-support" to ${misc:Depends}
> for any packages shipping libs under $prefix/lib/$tuple, and
> $I'm_not_sure_what_else_yet.
>
> Joey, do you have any timeline for a v9 release? It would be great to be
> able to coordinate this as closely as possible so that v9 is ready for
> deployment as soon as multiarch policy is finalized.I don't have a timeline. It's been quite a short time since 8.0.0. The only serious thing on my v9 todo list is DEB_OPTIONS_DEBUG and possibly something for #544844. However, I can start a v9 at any point, the typical process is to not close the compat level immediately, and so anything that uses it is responsible for dealing with any breakage introduced by later changes, until 9.0.0 is released. It does seem to me that it would be better to get basic support into debhelper generally w/o a v9. The kind of assurance I'm looking for is along the lines of scanning all debhelper config files in Debian to make sure none contain the new syntax somehow. While this seems unlikely, debhelper has enough users that any weird thing could be done by *someone*. -- see shy jo
signature.asc
Description: Digital signature
