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

Re: libstdc++ follow-up transitions



On 08/21/2015 01:12 PM, Simon McVittie wrote:
> On 18/08/15 00:37, Steve Langasek wrote:
>> On Mon, Aug 17, 2015 at 01:46:16PM +0100, Simon McVittie wrote:
>>> Having done more rebuilds in Ubuntu, it would be great if you could
>>> publish a complete list of the transitions you believe to be necessary
>>
>> Here's the count of source packages in Ubuntu wily that produce binary
>> packages ending in 'v5', which is probably a good approximation
> 
> Thanks, I have added them to <https://titanpad.com/UtA5km2wW6> so we can
> hopefully get a better picture of what needs to be done.
> 
> For the items that are still to-do or undecided, I've been adding
> reverse dependency counts to that list, using max(broken build-depends,
> source packages with broken depends) from a dak command like "dak rm -R
> -n adplug", so that people can see whether they are "almost leaf"
> packages or not. In most cases the answer is that they have < 10 direct
> rdeps, which strikes me as getting into "fix it later" territory.
> 
> hunspell is one notable exception, if it does indeed need renaming (I
> haven't verified)

it doesn't need it. For the history: In Ubuntu I started with the task to get a
cd image ready for GCC 5, manually renamed some library packages, and then we
uploaded all remaining packages for the image with a dependency on libstdc++6.
Then I asked for the renames based on these rebuilt packages, including some
which didn't need renaming. I asume these were about 5-10 library packages.  I
don't have a record anymore, the contents of the PPA is already removed.

> I think we might be at or approaching a point where it is worthwhile to
> schedule a significant number of binNMUs and make more of unstable
> installable again, without needing to re-binNMU too many of the same
> packages later? For instance, the ilmbase -> openexr -> opencv stack are
> all fixed in unstable, and so are most of the glibmm stack (e.g. gtkmm).

sure, but maybe make sure you limit the binNMUs first to packages not building
library packages.  This way you might catch some ftbfs indicating that more
renames are needed.

Matthias


Reply to: