Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more

[Fernando Rodriguez]

On Tuesday, August 25, 2015 7:58:44 PM Alan McKinnon wrote:
> On 25/08/2015 19:43, Fernando Rodriguez wrote:
> > On Tuesday, August 25, 2015 12:30:09 PM Alan McKinnon wrote:
> >> On 25/08/2015 04:28, Fernando Rodriguez wrote:
> >>> On Monday, August 24, 2015 9:31:38 PM Alan McKinnon wrote:
> >>>> Does anyone have an opinion to offer on bug 501468?
> >>>>
> >>>> https://bugs.gentoo.org/show_bug.cgi?id=501468
> >>>>
> >>>> It's been annoying me for a week now with this message:
> >>>>
> >>>> !!! existing preserved libs:
> >>>>>>> package: www-client/firefox-40.0.2
> >>>>  *  - /usr/lib64/firefox/libmozalloc.so
> >>>>  *      used by /usr/lib64/thunderbird/components/libdbusservice.so
> >>>> (mail-client/thunderbird-38.2.0)
> >>>>  *      used by /usr/lib64/thunderbird/components/libmozgnome.so
> >>>> (mail-client/thunderbird-38.2.0)
> >>>>  *      used by
> >>>> /usr/lib64/thunderbird/distribution/extensions/{e2fda1a4-762b-4020-
b5ad-
> >>> a41df1933103}/components/libcalbasecomps.so
> >>>> (mail-client/thunderbird-38.2.0)
> >>>>  *      used by 4 other files
> >>>>
> >>>>
> >>>> Both Mozilla products ship this file:
> >>>>
> >>>> $ locate libmozalloc
> >>>> /usr/lib64/firefox/libmozalloc.so
> >>>> /usr/lib64/thunderbird/libmozalloc.so
> >>>>
> >>>> and according to preserved libs, thunderbird linked to the firefox copy.
> >>>> The only offered solution on the bug is to use a MASK variable, which
> >>>> seems to me an ugly hammer to swat a fly.
> >>>>
> >>>> I was wondering if there's a better way been developed in the last
year.
> >>>
> >>> Actually, now I have a general idea of what's going on and that sounds
> > like an
> >>> acceptable solution but perhaps I could be better. This is what happens:
> >>>
> >>> 1. revdep-rebuild uses ldd to find breakage. It finds breakage in
> >>> libdbusservice.so because firefox uses tricks to preload the library from
> > it's
> >>> directory.
> >>> 2. revdep-rebuild find that thunderbird provides the library and thinks
it 
> >>> needs to be rebuild. (And wrongly tells you that firefox links against
it).
> >>>
> >>> A better way would be:
> >>>
> >>> 1. same as step 1 above
> >>> 2. revdep-rebuild checks the package that provides the broken binary (in
> > this
> >>> case the firefox package), if this package also provides the missing
> > library
> >>> then it's safe to ignore the problem.
> >>> 3. same as step 2 above.
> >>>
> >>> Another solution is to make patch firefox to use RPATH so ldd can find the
> >>> labraries, this would also make prelink work better with firefox but it's
> >>> probably not ideal to mantain.
> >>
> >>
> >> that does make sense. In my case, it's not revdep-rebuild causing
> >> problems, it's the preserved-rebuild message at the end of emerge -v
> >>
> >> At this level is there a difference?
> >
> > I don't know the details but it seems to me that portage either uses
revdep-
> > rebuild to find breakage (without scanning the whole system) before
deleting 
> > the old libs for good or duplicates some of it's logic. Come to think of
it, 
> > the SEARCH_DIR_MASK may not be ideal because if I understand what it does
> > correctly then real breakage in firefox won't be detected.
> >
>
> My thought too. To me, SEARCH_DIR_MASK is fine for things like
> /opt/skype because it's binary and either works or it doesn't, and when
> it doesn't there's not much I can do about it.
>
> It may be the least sucky of all available solutions, but it's still
> swatting a fly with a hammer

Maybe the bug should be filed against portage to get the right people to look 
at it. The fix should be simple, just check the package with the broken binary 
first. It seems to use lexical order so it finds firefox before thunderbird.

It would benefit binary packages too. You cannot rebuild skype but you can 
preserve the library until the vendor releases a new binary. You would get an 
endless preseved-libs loop for it but that's preferable to a broken skype.

-- 
Fernando Rodriguez