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 1IBjma-0000Yq-9P for garchives@archives.gentoo.org; Fri, 20 Jul 2007 04:08:00 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l6K46OLb017768; Fri, 20 Jul 2007 04:06:24 GMT Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.232]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l6K42vH7012494 for ; Fri, 20 Jul 2007 04:02:57 GMT Received: by nz-out-0506.google.com with SMTP id s18so677951nze for ; Thu, 19 Jul 2007 21:02:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=o3i2ejaNIaO1Jaz3MYdJegnoU7xATMJHo6VXvcUbSvOwEeRbhPG9JDl1lp258JeoYR5udt5a0HgdI65Oe6KJIwY2vibOn81khpkNghsxqfo9jqoLm5kr8i1JmXAopb0OFbMFSuK5mvbGYD4CzJ8RtHCXmR7Lptl8hA/5esDc1DY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hVDr0wBhPNSMslSODy7ftUODW1Mp9+NXZBPcP4nSdgZT030wyvSlxyXnNe05FDVo7Z4kLko6X7WfwqEkrHTCePktKq4TT35vgDeVFqlA9IMP6fpcdGu1L0Ih/khY++/OWg6afGOEuVMjHk9rPmFj9/gKJ7xPdh+k3kI4MxemDIM= Received: by 10.114.149.2 with SMTP id w2mr75343wad.1184904176525; Thu, 19 Jul 2007 21:02:56 -0700 (PDT) Received: by 10.115.18.13 with HTTP; Thu, 19 Jul 2007 21:02:56 -0700 (PDT) Message-ID: Date: Fri, 20 Jul 2007 00:02:56 -0400 From: "Eric Polino" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: net-im/pidgin protocols In-Reply-To: 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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <469F1C56.6070600@gentoo.org> <469F372A.9060107@gentoo.org> <469F3A9F.7030004@gentoo.org> <46A0DE7B.6030009@gentoo.org> X-Archives-Salt: a4e46f05-94f0-4e08-87c3-7b963ac606d5 X-Archives-Hash: 006e11fc0d3a50f197a3ee936ec13eb3 On 7/19/07, Duncan <1i5t5.duncan@cox.net> wrote: > "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. If this is truly a problem, then I think the negative USE flags might be the better solution then. This would allow users the ability to disable potential insecure features. But really, I doubt security is an issue here. > 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. I see your point, but how different would this be to any application that requires dependencies and you can't change the fact that they require them. For instance, any application that uses GTK+ requires GTK+ and there's nothing you can do about it. I don't care how much you strip down Firefox, you'll still need GTK+. The Pidgin team "sells" their application as having all these protocols so they should be there, at least out of the box. > >>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... Don't know what you mean here. > > 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^) Cool! Though PEBKAC is far too common than most would like to admit. I think you'd agree! > -- > 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 > > -- http://aluink.blogspot.com -- "...indexable arrays, which may be thought of as functions whose domains are isomorphic to contiguous subsets of the integers." --Haskell 98 Library Report -- gentoo-dev@gentoo.org mailing list