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

Re: libstdc++ follow-up transitions



On 17/08/15 11:07, Matthias Klose wrote:
> There seems to be a tendency to avoid transitions, where Debian doesn't have any
> reverse dependencies, or where developers analyze the library API's and come to
> the conclusion that no transition is necessary.  I'm not yet sure if this is the
> safest way forward, given the alternative of semi-automatic renaming of the
> packages.

Feel free to reopen the closed "maybe transition" bugs with stronger
wording if you believe we have been wrong to close them, although I hate
to think how long this process is going to take if we're requiring the
renames even for packages with no rdeps. Sorry, I had interpreted the
wording about "please determine whether a transition is necessary" as
what it said, rather than "please do a transition unless you are 100%
sure it is unnecessary"; so I had been trying to prune the "transition
set" in an attempt to make it finish in a finite time.

I notice that Ubuntu has gone ahead with a lot of library renames. Did
the Ubuntu developers doing these uploads test the results, or did you
just "upload and hope"? One reason I have held back from doing more NMUs
is that for the majority of transitioning packages, I have no idea how
to smoke-test the results, and I'm not happy with putting my signature
on a package that I haven't tested. However, if we're going for a lower
standard of "successfully rebuilding the package and some random rdeps
is enough testing", then there are quite a lot of NMUs that can be done.

If we wait for a maintainer who knows the relevant package (who is
likely on holiday and/or MIA in many cases) to inspect each of the
packages involved, then I don't think anything vaguely C++-related is
going to migrate for weeks, possibly months. That's a long time for
developers without the appropriate C++ or specific-library knowledge to
avoid touching unstable and hope security bug fixes get to them via t-p-u.

One complicating factor here is that the transitions are not all
currently RC. Are we considering these transitions, and anything that
blocks them, to be candidates for DELAYED/2 NMU regardless of severity?

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,
including those that are not ready to be uploaded until their
dependencies have transitioned, so we can get an idea of the size of the
problem.

    S


Reply to: