From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Fo4TI-0008AJ-7U for garchives@archives.gentoo.org; Wed, 07 Jun 2006 20:17:44 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k57KEutg002591; Wed, 7 Jun 2006 20:14:56 GMT Received: from egr.msu.edu (jeeves.egr.msu.edu [35.9.37.127]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k57K6UIt013290 for ; Wed, 7 Jun 2006 20:06:30 GMT Received: from [35.9.129.93] (torx [35.9.129.93]) (authenticated bits=0) by egr.msu.edu (8.13.6/8.13.4) with ESMTP id k57K6VRD011279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Jun 2006 16:06:31 -0400 (EDT) Message-ID: <4487319D.1000103@gentoo.org> Date: Wed, 07 Jun 2006 16:05:49 -0400 From: Alec Warner Organization: Gentoo User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060424) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1 References: <20060607151325.GA27076@nightcrawler> <200606071224.11042.vapier@gentoo.org> <44871B4E.7070909@gentoo.org> <20060607193157.GA15308@dst.grantgoodyear.org> In-Reply-To: <20060607193157.GA15308@dst.grantgoodyear.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: d5c88424-4d6d-4dd1-ae96-e33bce463036 X-Archives-Hash: 32617d6a5dec1ab3f1e913f1345ef98f Grant Goodyear wrote: > Zac Medico wrote: [Wed Jun 07 2006, 01:30:38PM CDT] > >>Mike Frysinger wrote: >> >>>this is a *huge* con ... developers are lazy, *i'm* lazy ... i >>>certainly do not want to go through every single package i maintain >>>and add 'debug-build' to IUSE or 'inherit some-new-eclass' >> >>Sometimes it takes a little extra work to do things right, but >>hopefully it will pay off in the long run. A poor design decision >>made now can haunt us for years to come. > > > A "little extra work"? I'm pretty sure that such an eclass would be > required for better than half the tree (every package that contains some > C or C++). If almost everybody has to add the same piece of > boilerplate to their ebuilds, then perhaps a sane package manager should > be able to figure out what to do without the boilerplate. That > rationale seems especially true in this case, where nostrip and > debugging flags will do no harm for packages that aren't C or C++. I tend to agree here on pragmatic principal as opposed to bowing to "this is the ideal case" that some members of the portage team seem to want. debug-build can always be expanded to turn on generic debugging for other build systems and languages. I realize it's not the "perfect solution." But no one has implemented a better one. People only wait so long for things before getting fed up and saying "it's going in anyway." > > >>>if the large majority of packages are going to be taking advantage of a >>>feature, isnt the logical thing to opt everyone in rather than forcing the >>>majority to opt themselves in ? >> >>It really depends on the pros/cons applying something on a *global* >>scale, like you propose. A package manager (such as portage) will >>never be able to make debug-build decisions that work well for *every* >>ebuild. That's why it's better for ebuilds to make those decisions >>themselves (with the help of eclasses). > > > I would think that your argument would depend on the probability of a > package being an exception to the general rule. How many packages > actually fail to do what is expected when compiled with -g and nostrip > (noting that those cases without binaries to strip don't count)? > Unless that percentage is significant, then I would think that a simple > solution that handles the common case is a very good thing. > > Wouldn't the "simple" solution be to have package.* files that allow the > user to specify FEATURES, CFLAGS, and CXXFLAGS per package? (Of course, > I do realize that it's the lack of such files that lead vapier to > propose his solution, which is rather more convenient for one-off > builds.) We've discussed this multiple times, and it's always been the conclusion that per package.env should go in bashrc, as bashrc is generally more powerful than anything we could devise. The only downside afaik, for bashrc is that you can't do per package FEATURES as FEATURES is a python-side var. But you shouldn't need per package FEATURES by design; FEATURES are for portage, not your ebuild. > > -g2boojum- -- gentoo-dev@gentoo.org mailing list