"Eric Polino" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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... <content for project or user omitted> 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 -- [EMAIL PROTECTED] mailing list