Re: Backport firmware updating stack to Jessie
Hi Gianfranco,
On Thu, Apr 21, 2016 at 12:54 AM, Gianfranco Costamagna
<locutusofborg@debian.org> wrote:
> Hi Vincent!
>
>
>>Errr, there are no rules against backporting packages with a different
>>soname compared to the corresponding versions in stable. I'm not even
>>sure how you would go about "mitigating" such changes, unless the
>>soname bumps were completely unnecessary to begin with. Would you care
>>to explain your rationale?
>
>
> Sometimes soname is changed because of Debian issues (e.g. libstdc++ transition
> where a lot of stuff has been renamed in "sonamev5")
> usually that sonamev5 is conflicting with soname version.
The libstdc++ transition did not involve soname changes to individual
packages; only package names changed (by having "v5" appended to the
name of all affected library packages). The reason why this can cause
potential breakage is more to do with the added conflicts+replaces
relationships in d/control for all packages that were required to be
rebuilt during the transition, and not because there were soname
changes involved.
FWIW, this has already been discussed on the list in the past, e.g. [1].
> backporting it means that you will have to choose one or the other (obviously).
>
> I forgot to rename them back for llvm-toolchain-3.5 backport to jessie (needed
> to build ghc on backports/arm*)
>
> I got some bug reports saying "installing it from backports will remove half of my system).
Again, caused by added conflicts+replaces due to the libstdc++
transition, not by soname changes...
> My testing was performed in a clean jessie-bpo environment, without many applications installed
> (and was related to the pieces of software needed to build ghc).
> So I unintentionally broke end users systems, where lots of more package are installed.
>
> So, I had to quickly backport a new llvm-toolchain-3.5 without the SONAME change (because there was no
> libstdc++ issue on jessie of course), and everything became good again after some hours.
>
> this is what I wonder when backporting new libraries with different SONAMEs.
>
> sometimes they break the old soname, for various reasons, leaving the user to make choices between
> one or the other
> (but I agree, probably on 99% of the use-cases different soname libraries aren't an issue
> and perfectly installable together in the system).
>
> Just I think backporting them needs a deeper inspection, and much more analysis.
FWIW, I've backported packages that had soname changes myself and
haven't experienced any problems doing so (that are unrelated to the
libstdc++ transition). I don't see how backporting libraries that have
undergone a soname change require any more analysis/inspection than
any other package. Just my $0.02, I suppose.
Regards,
Vincent
[1] https://lists.debian.org/debian-backports/2015/08/msg00061.html
Reply to: