Markos Chandras <hwoar...@gentoo.org> said: > On Tue, Aug 10, 2010 at 06:31:52PM -0400, Mike Frysinger wrote: > > On Tue, Aug 10, 2010 at 5:53 PM, Markos Chandras wrote: > > >> It seems like few of our fellow developers don't know how to track > > >> down > > >> packages that don't respect LDFLAGS. Adding -Wl,--hash-style=gnu > > >> is a good way > > >> to do that. I would like to see this linker flag enabled by > > >> default on LDFLAGS > > >> (or at least for the dev/ profiles for now). Do you agree? > > > > > > I would really really *really* appreciated if our beloved arch > > > testers ( at least for linux amd64/x86 because they are the first > > > who stabilize a package ) make this default on their build boxes. > > > > sounds like someone needs to update/extend the arch testing > > documentation. random e-mails posted to random dev lists are quickly > > forgotten. new arch testers however should be reading the arch > > tester documnt. > > I will update the guide for amd64 HT and I will strongly advice the > rest of the arches to do that as well. Using my QA powerzzz I will be > quite strict from now on with arches making such stabilizations.
i agree on this. packages on which portage complains about stuff like dohtml: bla file not found should not be marked stable. arch testers should not let stuff like this pass by. of course, neither should developers. but then again, we need better documentation of all of this. lyckily, the wiki effort has been killed off by a recent cabal</sarcasm> kind regards Thilo > > > > It is annoying to mark a package stable when it has *clear* QA > > > problems. > > > > please dont blow this out of proportion. two points: > > - stabilizing newer versions of a package when there is no QA > > > > regression is fine. > > Fair enough, still those QA need fixing. The fact that these QA probs > are not regressions doesn't mean it is ok to ignore them > > > - ignoring LDFLAGS, while incorrect, is rarely going to lead to > > > > broken packages being emerged on end users' systems. ignoring > > CFLAGS/CXXFLAGS however is much more likely to result in problems for > > end users when working with multilib or cross builds. > > -mike > > Of course. Respecting any *FLAGS is vital and definitely ony of the > many reasons we use Gentoo.
signature.asc
Description: This is a digitally signed message part.
