RE: Backport firmware updating stack to Jessie
> -----Original Message-----
> From: vincentc1208@gmail.com [mailto:vincentc1208@gmail.com] On Behalf
> Of Vincent Cheng
> Sent: Thursday, April 21, 2016 3:07 AM
> To: Gianfranco Costamagna <locutusofborg@debian.org>
> Cc: Limonciello, Mario <Mario_Limonciello@Dell.com>; debian-
> backports@lists.debian.org
> Subject: 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.
>
Thanks for the feedback guys. I didn't add any conflicts/replaces as part of my backports. Any soname changes that had happened in these packages should be justified, because the underlying libraries had changed. I don't see any of those packages names changing from a recompile against a new toolchain either.
So what do I need to do on my end next?
Show that installing the whole series of packages works properly in a stable install (with backports enabled + my repo that has the extra backports I'm proposing) without causing anything to get removed?
Reply to: