Bug 517154 – libtool.eclass: make --reverse-deps default for elibtoolize?

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Pacho Ramos 2014-07-15 13:40:13 UTC]

From time to time we get reports about some packages wrongly linking to already installed libs. Most of them can be fixed running elibtoolize with this option... then, I wonder if we could apply this patch by default to not need to wait for people to hit this kind of issue (that is sometimes a bit hard to detect)

Thanks a lot

[Comment 1 SpanKY 2014-08-04 09:09:31 UTC]

it's always been this way:
http://sources.gentoo.org/gentoo-x86/eclass/libtool.eclass?r1=1.9&r2=1.10

but i can't think of a reason to not enable it by default.  would be nice if we could do some tree wide testing first.

[Comment 2 Pacho Ramos 2014-08-04 10:04:29 UTC]

Looks like flameeyes is not running tinderbox for some time, but I recently got reports from Patrick Lauer that looks to have some kind of tinderbox setup that maybe could help for this :/

[Comment 3 Pacho Ramos 2015-01-19 22:38:24 UTC]

I know Toralf has a tinderbox setup, but I am not sure if he would be willing to try this, if not, no problem of course :)

[Comment 4 Toralf Förster 2015-01-20 19:17:11 UTC]

(In reply to Pacho Ramos from comment #3)
> I know Toralf has a tinderbox setup, but I am not sure if he would be
> willing to try this, if not, no problem of course :)

I do have in fact 3 chroot images at a dedicated server:
amd64, ~amd64 and ~hardened
What do you like to test ?

[Comment 5 Pacho Ramos 2015-01-20 21:52:51 UTC]

I think amd64 would fit better as the change in eclass would affect stable too, regarding hardened or not, I guess it doesn't mind for this case :/

[Comment 6 Toralf Förster 2015-01-25 09:04:38 UTC]

(In reply to Pacho Ramos from comment #5)
> I think amd64 would fit better as the change in eclass would affect stable
> too, regarding hardened or not, I guess it doesn't mind for this case :/

Ok, so I'd just clone the stable chroot amd64 and put the line
  ELTCONF="--reverse-deps"
into make.conf ?

[Comment 7 Pacho Ramos 2015-01-25 11:39:21 UTC]

I don't know if that would be enough, if I would be going to test it I would edit my local libtool.eclass to replace:
local do_reversedeps="no"

to
local do_reversedeps="yes"

to be 100% sure it's applied

[Comment 8 Toralf Förster 2015-01-25 22:34:48 UTC]

(In reply to Pacho Ramos from comment #7)
> I don't know if that would be enough, if I would be going to test it I would
> edit my local libtool.eclass to replace:
> local do_reversedeps="no"
> 
> to
> local do_reversedeps="yes"
> 
> to be 100% sure it's applied

did it at a cloned amd64 chroot - now 2 stable amd64 chroots are running here, one original and one patched

[Comment 9 Pacho Ramos 2015-04-18 12:51:34 UTC]

Did something break finally? Thanks

[Comment 10 Toralf Förster 2015-04-18 13:22:26 UTC]

(In reply to Pacho Ramos from comment #9)
> Did something break finally? Thanks

No - the opposite is true.

Although it is just a feeling (I don't collect numbers), it seems, that the -libtool tinderboxes survives longer than their un-patched sibblings (said that before they run into flip-flop revdep-rebuilds mess or something in that direction)

[Comment 11 Pacho Ramos 2015-04-18 13:43:31 UTC]

Oh nice, lets see if vapier has a bit of time to finally change this ;)

Thanks for your help!

[Comment 12 Pacho Ramos 2015-07-09 09:38:06 UTC]

@vapier, is anything more pending to finally solve this? Thanks a lot :)

[Comment 13 Pacho Ramos 2015-11-19 12:25:15 UTC]

ping :/

[Comment 14 Pacho Ramos 2016-01-20 11:37:46 UTC]

Any news on this? We are wondering about adding it to gnome2.eclass (bug 523614) but this would benefit all the people, not only eclass consumers

Thanks

[Comment 15 Robin Johnson 2016-02-04 19:38:43 UTC]

@pacho:
Did it get well tested? If not, can we see about enabling it for ~arch users only?

[Comment 16 Pacho Ramos 2016-02-06 13:38:22 UTC]

Toralf tried it some months ago in his tinderbox and things went well is seems :/

[Comment 17 Toralf Förster 2016-02-06 14:47:32 UTC]

(In reply to Pacho Ramos from comment #16)
Can continue the tests further, would adding --reverse-deps" to EMERGE_DEFAULTS_OPTS be sufficient ?

[Comment 18 Toralf Förster 2016-02-06 14:58:14 UTC]

(In reply to Toralf Förster from comment #17)
ah - much better :

ms-magpie portage # git diff
diff --git a/eclass/libtool.eclass b/eclass/libtool.eclass
index 9434480..47ef812 100644
--- a/eclass/libtool.eclass
+++ b/eclass/libtool.eclass
@@ -138,7 +138,7 @@ elibtoolize() {
        local x
        local dirs=()
        local do_portage="no"
-       local do_reversedeps="no"
+       local do_reversedeps="yes"
        local do_only_patches="no"
        local do_uclibc="yes"
        local deptoremove=

b/c such a change won't be overwritten immediately using git instead rsync.

[Comment 19 Pacho Ramos 2016-02-08 12:22:25 UTC]

Yeah, it looks it was the way you run your tinderbox last time for this :)

Anyway, I am unsure if another tinderbox run is needed for this :/

[Comment 20 Pacho Ramos 2016-02-19 16:22:10 UTC]

What is blocking this then?

[Comment 21 Doug Goldstein (RETIRED) 2016-02-28 18:34:40 UTC]

I'm good with this going on. Mike or Robin, do you guys want to weigh in? Pacho, if you haven't heard anything in a week then I say do it.

[Comment 22 Pacho Ramos 2016-04-03 12:50:15 UTC]

[master 1eb13e1] libtool.eclass: enable reversedeps patch (#517154)
 1 file changed, 1 insertion(+), 1 deletion(-)