Re: Backport firmware updating stack to Jessie
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.
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).
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.
my .02$
Gianfranco
Reply to: