From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from <gentoo-user+bounces-100631-garchives=archives.gentoo.org@lists.gentoo.org>) id 1MplZ3-0006S2-UT for garchives@archives.gentoo.org; Mon, 21 Sep 2009 16:16:34 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E5A23E08AB; Mon, 21 Sep 2009 16:16:32 +0000 (UTC) Received: from qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.150]) by pigeon.gentoo.org (Postfix) with ESMTP id BE5B7E08AB for <gentoo-user@lists.gentoo.org>; Mon, 21 Sep 2009 16:16:32 +0000 (UTC) Received: by qw-out-1920.google.com with SMTP id 4so1079342qwk.10 for <gentoo-user@lists.gentoo.org>; Mon, 21 Sep 2009 09:16:32 -0700 (PDT) Precedence: bulk List-Post: <mailto:gentoo-user@lists.gentoo.org> List-Help: <mailto:gentoo-user+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-user.gentoo.org> X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.229.10.214 with SMTP id q22mr1165732qcq.91.1253549792395; Mon, 21 Sep 2009 09:16:32 -0700 (PDT) Date: Mon, 21 Sep 2009 09:16:32 -0700 Message-ID: <5061b39c0909210916u38206918j41e7917609cb2f76@mail.gmail.com> Subject: [gentoo-user] Gentoo Portage Feature Request From: Paige Thompson <erratic@devel.ws> To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=0016364ed56e15845f047418cedc X-Archives-Salt: af2e802e-3ed2-42d2-ae36-0ea4a1a68146 X-Archives-Hash: 2a15ad5a359662549ae4b85ba1d1f89c --0016364ed56e15845f047418cedc Content-Type: text/plain; charset=UTF-8 I hope nobody finds this offensive, I'm not a great writer but I gotta get this out there. Goal: to resolve quality issues with packages and the behavior of portage Problem 1: This is a really simple thing, first of all it would help a lot if packages will not try to build with specified cxxflags if the maintainer hasn't tested the build and enabled them for that package. case and point: I have -fstack-protector-all in my cxxflags because I'm a paranoid idiot and I'm overly confident that it could never be wrong to have that. emacs, fails to build because of it but it's not obvious. I file a really pedantic bug report, and later through trial and error and after having gotten over my confidence in -fstack-protector-all realized that without it the package *does* build. If the ebuild had a feature where it's metadata did not indicate that it could build with that cxxflag, then portage could stop and just tell me that up front *OR* prompt me and ask me what do next. I understand that this would require package maintainers to actually *test* their packages which is no trivial issue, and who wouldn't agree that if they're not willing to then somebody else should? Not only that but it gives you the ability to score maintainers based on the accuracy of the results. I'm not even suggesting that this feature should be mandatory it could be something that I could turn on or off-- I just want it so that I know what's going on and I don't end up wasting people's time filing bug reports and making them mad at me for being a noob. Problem 2: I know this is might be kind of nitpicky to you, and it's more or less the same as problem 1 but I think if I specify -O0 in my cxxflags, that a package that needs -O2 should not build and tell me that it needs it rather than just building with -O2 anyway!! I mean seriously, why even give me the option to specify the optimization level in the cxxflags. It's deceptive, I don't like that I find it very difficult to take it seriously because of that. -Paige Thompson erratic@devel.ws saved on 9/21/09 8:41 AM by Paige Thompson --0016364ed56e15845f047418cedc Content-Type: text/html; charset=UTF-8 <span class="postbody">I hope nobody finds this offensive, I'm not a great writer but I gotta get this out there.<br><br>Goal: to resolve quality issues with packages and the behavior of portage <br> <br> Problem 1: <br> <br> This is a really simple thing, first of all it would help a lot if packages will not try to build with specified cxxflags if the maintainer hasn't tested the build and enabled them for that package. <br> <br> case and point: <br>I have -fstack-protector-all in my cxxflags because I'm a paranoid idiot and I'm overly confident that it could never be wrong to have that. emacs, fails to build because of it but it's not obvious. I file a really pedantic bug report, and later through trial and error and after having gotten over my confidence in -fstack-protector-all realized that without it the package *does* build. If the ebuild had a feature where it's metadata did not indicate that it could build with that cxxflag, then portage could stop and just tell me that up front *OR* prompt me and ask me what do next. I understand that this would require package maintainers to actually *test* their packages which is no trivial issue, and who wouldn't agree that if they're not willing to then somebody else should? Not only that but it gives you the ability to score maintainers based on the accuracy of the results. I'm not even suggesting that this feature should be mandatory it could be something that I could turn on or off-- I just want it so that I know what's going on and I don't end up wasting people's time filing bug reports and making them mad at me for being a noob. <br> <br> Problem 2: <br>I know this is might be kind of nitpicky to you, and it's more or less the same as problem 1 but I think if I specify -O0 in my cxxflags, that a package that needs -O2 should not build and tell me that it needs it rather than just building with -O2 anyway!! I mean seriously, why even give me the option to specify the optimization level in the cxxflags. It's deceptive, I don't like that I find it very difficult to take it seriously because of that. <br> <br> -Paige Thompson <br> <a href="mailto:erratic@devel.ws">erratic@devel.ws</a> <br> saved on 9/21/09 8:41 AM by Paige Thompson</span> --0016364ed56e15845f047418cedc--