Summary: | libtool.eclass: make --reverse-deps default for elibtoolize? | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Pacho Ramos <pacho> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | toralf |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=523614 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Pacho Ramos
![]() 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. 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 :/ 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 :) (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 ? 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 :/ (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 ? 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 (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 Did something break finally? Thanks (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) Oh nice, lets see if vapier has a bit of time to finally change this ;) Thanks for your help! @vapier, is anything more pending to finally solve this? Thanks a lot :) ping :/ 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 @pacho: Did it get well tested? If not, can we see about enabling it for ~arch users only? Toralf tried it some months ago in his tinderbox and things went well is seems :/ (In reply to Pacho Ramos from comment #16) Can continue the tests further, would adding --reverse-deps" to EMERGE_DEFAULTS_OPTS be sufficient ? (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. 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 :/ What is blocking this then? 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. [master 1eb13e1] libtool.eclass: enable reversedeps patch (#517154) 1 file changed, 1 insertion(+), 1 deletion(-) |