On 7/19/07, Duncan <[EMAIL PROTECTED]> wrote:
"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.
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... <content for project or user omitted>
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
--
[EMAIL PROTECTED] 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
--
[EMAIL PROTECTED] mailing list
