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.62) (envelope-from ) id 1IBj7R-0001NM-Na for garchives@archives.gentoo.org; Fri, 20 Jul 2007 03:25:30 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l6K3OMPh030906; Fri, 20 Jul 2007 03:24:22 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l6K3MaVw028697 for ; Fri, 20 Jul 2007 03:22:36 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 28FC165493 for ; Fri, 20 Jul 2007 03:22:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -1.165 X-Spam-Level: X-Spam-Status: No, score=-1.165 required=5.5 tests=[AWL=-1.166, BAYES_50=0.001] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQ7enIBgaXit for ; Fri, 20 Jul 2007 03:22:34 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 61B0D6547D for ; Fri, 20 Jul 2007 03:22:32 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IBj4S-00082w-FN for gentoo-dev@gentoo.org; Fri, 20 Jul 2007 05:22:24 +0200 Received: from ip68-230-68-110.ph.ph.cox.net ([68.230.68.110]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Jul 2007 05:22:24 +0200 Received: from 1i5t5.duncan by ip68-230-68-110.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Jul 2007 05:22:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: net-im/pidgin protocols Date: Fri, 20 Jul 2007 03:22:17 +0000 (UTC) Message-ID: References: <469F1C56.6070600@gentoo.org> <469F372A.9060107@gentoo.org> <469F3A9F.7030004@gentoo.org> <46A0DE7B.6030009@gentoo.org> 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-68-110.ph.ph.cox.net User-Agent: Pan/0.131 (Ghosts: First Variation) Sender: news X-Archives-Salt: 181658f8-6e41-4cb0-998d-7e0974dc94f9 X-Archives-Hash: 60af804f243496e98b338d9f14bbf98c "Eric Polino" posted b21328ed0707191852o3ec406b6ga325c70951d83adc@mail.gmail.com, excerpted below, on Thu, 19 Jul 2007 21:52:16 -0400: >> OTOH, if enabling those protocols pulls in all sorts of additional >> packages to support them, shipping with everything on just because it's >> possible is not the Gentoo way. That's what USE flags are for. If >> indeed additional dependencies are pulled in, IMO the USE flags should >> remain, > > Yes there would be a few other small supporting packages. They, at > most, would use a few extra 100K of RAM and a small amount of disk > space. Considering that pidgin is a GTK+ application, it would imply > someone is running X and thus can afford to use a little extra RAM being > used. They are small packages and would probably take less than a > minute or two of extra compile time. Considering that Pidgin takes > about 5-10 minutes to compile give or take, this is negligible. I may well be in the minority on this, but here it's not so much the compile time or space I'm worried about, but the whole security thing of not installing stuff that I'm not going to use and shouldn't need. To be clear, if it's simply the USE flag defaults under debate, not a problem. Portage (and I assume the alternatives) already makes it easy to see and change those for those that care about such things. Someone mentioned just killing the USE flags and making them all hard dependencies, however. I really hope that's not done if additional dependencies are involved. >>and maybe someone needs to explain the Gentoo way to upstream. > > I agree with the Gentoo way in most cases, hence why I use Gentoo. But > in this case the Gentoo way fails. It creates more problems than it > solves. Like was mentioned above, if people read ewarns or ran -pv we > wouldn't be having this problem, but most don't. Unfortunately, their > negligence becomes our headache and this is what I'm trying to solve. I > don't think the drawbacks of installing a few extra packages for the > greater good of less headaches for both users and upstream are worth not > making this change. People not running -pv or -av... The ewarn thing, however, is now changing for the better, thanks to our hard working portage devs. =8^) It may not be in stable yet, but at least ~arch portage now reprints ewarns and the like at the END of the merge, by default. The problem before was that unless the package happened to be the last one merged, all the output got lost way up the scrollback somewhere. With portage now reprinting the (level configurable, sane defaults) message output for all merged packages again at the END of the merge, it's far far more likely that users actually see and read it. As I said, it has already made a BIG difference here. Major major kudos to the portage guys for implementing it! =8^) Once a portage with this feature is stable and widely deployed, it's likely there'll be a noticeable reduction in "PEBKAC" bugs due to not reading these messages. This I can say from actual use! =8^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@gentoo.org mailing list