Mailing List Archive

another option could just be to enable the protocols in the ebuild by
default (or does that have to be done globally in profile?) and force users
to turn them off if they don't want them.

On 7/19/07, Eric Polino <aluink@gmail.com> wrote:
>
> Would it be possible to have all the protocols for net-im/pidgin
> turned on by default. We often get people coming to #pidgin looking
> for help as to why they can't get MSN or some other protocol working.
> It most often is because they haven't enabled the given protocol USE
> flag.
>
> There is nothing gained in turning a protocol off. At the very most
> you might save on 100K of memory, and a small amount of compile time
> (pidgin takes a good while to compile, so this is a small percentage).
> On the other hand, by having them off by default, people often lose a
> lot of time figuring out why they are missing some protocol. Finding
> out which ones they want, setting up package.use... The wanted gain
> is lost in research and setup time. I would understand if they were
> huge aspects of the application that took up tons of HD space, tons of
> RAM and took a while to compile, but they aren't.
>
> I have two suggestions for solutions. The protocol flags could be
> removed and would make them on all the time. Or if the overzealous
> user insists on having some off, there could be negative flags such as
> nomsn, noaim, etc.
>
> I am busy with a GSoC project right now, but I can offer a diff for an
> ebuild that would provide this functionality once I find time to.
>
> Thanks,
> Eric
>
> --
> 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
>
>


--
Caleb Cushing

On 7/19/07, Caleb Cushing <xenoterracide@gmail.com> wrote:
> another option could just be to enable the protocols in the ebuild by
> default (or does that have to be done globally in profile?) and force users
> to turn them off if they don't want them.

Yeah that would have to be done in the profile. We could have
extended use flags added that are on by default in the profile.
Though I would think this to be overkill for this problem.

> On 7/19/07, Eric Polino <aluink@gmail.com> wrote:
> >
> > Would it be possible to have all the protocols for net-im/pidgin
> > turned on by default. We often get people coming to #pidgin looking
> > for help as to why they can't get MSN or some other protocol working.
> > It most often is because they haven't enabled the given protocol USE
> > flag.
> >
> > There is nothing gained in turning a protocol off. At the very most
> > you might save on 100K of memory, and a small amount of compile time
> > (pidgin takes a good while to compile, so this is a small percentage).
> > On the other hand, by having them off by default, people often lose a
> > lot of time figuring out why they are missing some protocol. Finding
> > out which ones they want, setting up package.use... The wanted gain
> > is lost in research and setup time. I would understand if they were
> > huge aspects of the application that took up tons of HD space, tons of
> > RAM and took a while to compile, but they aren't.
> >
> > I have two suggestions for solutions. The protocol flags could be
> > removed and would make them on all the time. Or if the overzealous
> > user insists on having some off, there could be negative flags such as
> > nomsn, noaim, etc.
> >
> > I am busy with a GSoC project right now, but I can offer a diff for an
> > ebuild that would provide this functionality once I find time to.
> >
> > Thanks,
> > Eric
> >
> > --
> > 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
> >
> >
>
>
>
> --
> Caleb Cushing


--
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

Eric Polino wrote:
> Would it be possible to have all the protocols for net-im/pidgin
> turned on by default. We often get people coming to #pidgin looking
> for help as to why they can't get MSN or some other protocol working.
> It most often is because they haven't enabled the given protocol USE
> flag.

looks like it's another case for IUSE defaults

make sense leaving a big glowing ewarn about it anyway, no point in
getting pidgin people pissed of at us again because of our users.

lu - that will haunt #pidgin now and then asking for the updated y! protocol

--

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@gentoo.org mailing list

Luca Barbato kirjoitti:
> Eric Polino wrote:
>> Would it be possible to have all the protocols for net-im/pidgin
>> turned on by default. We often get people coming to #pidgin looking
>> for help as to why they can't get MSN or some other protocol working.
>> It most often is because they haven't enabled the given protocol USE
>> flag.
>
> looks like it's another case for IUSE defaults
>
> make sense leaving a big glowing ewarn about it anyway, no point in
> getting pidgin people pissed of at us again because of our users.
>
> lu - that will haunt #pidgin now and then asking for the updated y! protocol
>

Or just do it via package.use in profiles until IUSE defaults are
implemented.

Regards,
Petteri

Petteri Räty napsal(a):
> Or just do it via package.use in profiles until IUSE defaults are
> implemented.
>
> Regards,
> Petteri

As noted before, they are implemented, just not allowed in the tree.
Plus, what vapier said, this info belongs to the ebuilds, not to profiles.

Wrt pidgin - seriously, what's the big issue here? Users can't use
emerge -pv output and determine what they want, or? Will we bloat the
profiles everytime someone forgets to enable a flag and goes complain
upstream about a 'missing' feature?


--
Best regards,

Jakub Moc
mailto:jakub@gentoo.org
GPG signature:
http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E

... still no signature ;)

Jakub Moc kirjoitti:
> Petteri Räty napsal(a):
>> Or just do it via package.use in profiles until IUSE defaults are
>> implemented.
>>
>> Regards,
>> Petteri
>
> As noted before, they are implemented, just not allowed in the tree.
> Plus, what vapier said, this info belongs to the ebuilds, not to profiles.
>
> Wrt pidgin - seriously, what's the big issue here? Users can't use
> emerge -pv output and determine what they want, or? Will we bloat the
> profiles everytime someone forgets to enable a flag and goes complain
> upstream about a 'missing' feature?
>

The policy is to have sane defaults for emerge <application>. OK good
that they are implemented. Let's say then until EAPI-1 is approved instead.

Regards,
Petteri

On Thu, 19 Jul 2007 12:19:11 +0200
Jakub Moc <jakub@gentoo.org> wrote:
> As noted before, they are implemented, just not allowed in the tree.
> Plus, what vapier said, this info belongs to the ebuilds, not to
> profiles.

What, it belongs in multiple ebuild files, rather than a single profile
file?

--
Ciaran McCreesh

Ciaran McCreesh kirjoitti:
> On Thu, 19 Jul 2007 12:19:11 +0200
> Jakub Moc <jakub@gentoo.org> wrote:
>> As noted before, they are implemented, just not allowed in the tree.
>> Plus, what vapier said, this info belongs to the ebuilds, not to
>> profiles.
>
> What, it belongs in multiple ebuild files, rather than a single profile
> file?
>

Let's not get into this debate in this thread. There was a thread that
was discussing this a while ago so all the argumentation about the
general case belongs there.

Regards,
Petteri

On Thu, 2007-07-19 at 12:19 +0200, Jakub Moc wrote:
> Petteri Räty napsal(a):
> > Or just do it via package.use in profiles until IUSE defaults are
> > implemented.
> >
> > Regards,
> > Petteri
>
> As noted before, they are implemented, just not allowed in the tree.
> Plus, what vapier said, this info belongs to the ebuilds, not to profiles.
>
> Wrt pidgin - seriously, what's the big issue here? Users can't use
> emerge -pv output and determine what they want, or? Will we bloat the
> profiles everytime someone forgets to enable a flag and goes complain
> upstream about a 'missing' feature?

Unfortunately, that is the state we're currently in with regards to our
profiles and the tree. I know I would *love* to see us start using IUSE
defaults as soon as possible in the tree. It really would keep the
profiles from bloating out too much with ebuild-specific USE flags and
such. Also, we (releng) have a current policy of not really allowing
local USE in the profiles unless we absolutely have to do so. I mean in
USE in make.defaults, not in package.use, which is perfectly acceptable.

--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

2007-07-19 18:52:59 Chris Gianelloni napisał(a):
> On Thu, 2007-07-19 at 12:19 +0200, Jakub Moc wrote:
> > Petteri Räty napsal(a):
> > > Or just do it via package.use in profiles until IUSE defaults are
> > > implemented.
> > >
> > > Regards,
> > > Petteri
> >
> > As noted before, they are implemented, just not allowed in the tree.
> > Plus, what vapier said, this info belongs to the ebuilds, not to
> > profiles.
> >
> > Wrt pidgin - seriously, what's the big issue here? Users can't use
> > emerge -pv output and determine what they want, or? Will we bloat the
> > profiles everytime someone forgets to enable a flag and goes complain
> > upstream about a 'missing' feature?
>
> Unfortunately, that is the state we're currently in with regards to our
> profiles and the tree. I know I would *love* to see us start using IUSE
> defaults as soon as possible in the tree.

So just start using IUSE defaults! There's no problem with doing it at once
since it can be considered as a part of EAPI=0.

- --
Arfrever Frehtes Taifersar Arahesis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.5 (GNU/Linux)

iD8DBQFGn5rN/axNJ4Xo/ZERAkQkAJ9W0+c4+sSVNWTIgZQsavHMQsbKvgCfTdVq
F2sZo6zkymYT4/A30k/c/Wg=
=VZZf
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

On 19/07/07, Arfrever Frehtes Taifersar Arahesis <arfrever.fta@gmail.com> wrote:
> > Unfortunately, that is the state we're currently in with regards to our
> > profiles and the tree. I know I would *love* to see us start using IUSE
> > defaults as soon as possible in the tree.
>
> So just start using IUSE defaults! There's no problem with doing it at once
> since it can be considered as a part of EAPI=0.

Uhh, no it can't. That's the point of EAPI. Ebuilds with different
EAPIs are incompatible, so if you start shoving '+'s in IUSE without
setting EAPI to 1, all the pm's should explode rather noisily. (Unless
you're talking about using package.use in profiles/, which iirc can be
used with EAPI 0 ebuilds).


--
-Charlie
--
gentoo-dev@gentoo.org mailing list

On Thu, 19 Jul 2007 19:08:20 +0200
Arfrever Frehtes Taifersar Arahesis <arfrever.fta@gmail.com> wrote:
> So just start using IUSE defaults! There's no problem with doing it
> at once since it can be considered as a part of EAPI=0.

No, IUSE defaults are EAPI 1.

--
Ciaran McCreesh

Alright, well I appreciate all the thought and discussion that
exploded about this problem. The pidgin team appreciates it. Though
I'm sorry to say I'm not up to speed with all this Gentoo talk. I
gather that when IUSE defaults come out, the ability to specify
default USE flags on a per package basis will be available in the
ebuild, but other than that I'm somewhat lost as to what was just
talked about. Can someone break it down for a simple user/would like
to be maintainer someday, so that I can have a better cleaner answer
to bring back to the pidgin team.

Thanks again,
Eric

On 7/19/07, Ciaran McCreesh <ciaranm@ciaranm.org> wrote:
> On Thu, 19 Jul 2007 19:08:20 +0200
> Arfrever Frehtes Taifersar Arahesis <arfrever.fta@gmail.com> wrote:
> > So just start using IUSE defaults! There's no problem with doing it
> > at once since it can be considered as a part of EAPI=0.
>
> No, IUSE defaults are EAPI 1.
>
> --
> Ciaran McCreesh
>
>
>


--
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

Eric Polino wrote:
> Alright, well I appreciate all the thought and discussion that
> exploded about this problem. The pidgin team appreciates it. Though
> I'm sorry to say I'm not up to speed with all this Gentoo talk. I
> gather that when IUSE defaults come out, the ability to specify
> default USE flags on a per package basis will be available in the
> ebuild, but other than that I'm somewhat lost as to what was just
> talked about. Can someone break it down for a simple user/would like
> to be maintainer someday, so that I can have a better cleaner answer
> to bring back to the pidgin team.

I believe the short answer is:

- Yes, we /could/ do this now in the profile.
- Once IUSE defaults are allowed, we can then do it in a different
(perhaps better?) way.

The question remaining yet that I've seen no answer for yet:

Will we do it now in the profile?

Or will we instead just have a big notice in the ebuild that says "You
may be missing protocols because of your USE flags, please
check your USE flags and maybe re-emerge pidgin again if you forgot
some protocol you really wanted"

At least that's how I read this thread.

I'm all for doing it now in the profile, but it's not my package.
Perhaps someone from the net-im herd can make this decision?

--
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)

On Thu, 2007-07-19 at 16:02 -0600, Jim Ramsay wrote:
> I'm all for doing it now in the profile, but it's not my package.
> Perhaps someone from the net-im herd can make this decision?

Well, as someone who spends a lot of time working on/with profiles, I
say go for it. Since these changes would only affect the one package
and wouldn't pull in any "strange" dependencies on people, we should
probably do it as high in the profile structure as possible (base?
default-linux?) so it hits the most users.

I'd like to hear from net-im, as they're ultimately responsible, but I
don't really see the harm in doing it, so we probably should as it will
reduce headaches for our users.

--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

On Thu, 2007-19-07 at 15:22 -0700, Chris Gianelloni wrote:
> On Thu, 2007-07-19 at 16:02 -0600, Jim Ramsay wrote:
> > I'm all for doing it now in the profile, but it's not my package.
> > Perhaps someone from the net-im herd can make this decision?
>
> Well, as someone who spends a lot of time working on/with profiles, I
> say go for it. Since these changes would only affect the one package
> and wouldn't pull in any "strange" dependencies on people, we should
> probably do it as high in the profile structure as possible (base?
> default-linux?) so it hits the most users.
>
> I'd like to hear from net-im, as they're ultimately responsible, but I
> don't really see the harm in doing it, so we probably should as it will
> reduce headaches for our users.

Talking with my net-im hat, I'd say go for it.. Except for silc and
zephyr (which may or may not work very well) and should probably stay
off.

--
Olivier Crête
tester@gentoo.org
Gentoo Developer

joshua jackson <tsunam@gentoo.org> posted 46A0DE7B.6030009@gentoo.org,
excerpted below, on Fri, 20 Jul 2007 09:10:35 -0700:

> Honestly..this is not something to get picky over jakub. Upstream was
> nice and actually came and politely asked us to change the defaults to
> what most people would consider sane (all protocols by default). As I
> think most people emerging pidgin..would like to use any protocol by
> default..not go..hey I don't have yahoo, I should check my use flags.
> Which obviously hasn't happened as users pop up in #pidgin to ask why
> the heck there isn't a yahoo account available.

[Dev-discussion, so kept posted here.]

I've not seen this question come up yet, so I'll raise it.

Shouldn't the question really depend on whether optional dependencies are
pulled in by the protocols or not? If everything's pidgin internal, then
if upstream wants all the protocols on as shipped, I think that's the
sane thing to do.

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, and maybe someone needs to explain the Gentoo way to upstream.

--
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

On 7/19/07, Duncan <1i5t5.duncan@cox.net> wrote:
> joshua jackson <tsunam@gentoo.org> posted 46A0DE7B.6030009@gentoo.org,
> excerpted below, on Fri, 20 Jul 2007 09:10:35 -0700:
>
> > Honestly..this is not something to get picky over jakub. Upstream was
> > nice and actually came and politely asked us to change the defaults to
> > what most people would consider sane (all protocols by default). As I
> > think most people emerging pidgin..would like to use any protocol by
> > default..not go..hey I don't have yahoo, I should check my use flags.
> > Which obviously hasn't happened as users pop up in #pidgin to ask why
> > the heck there isn't a yahoo account available.

This is precisely my point, glad to hear it's gotten across to someone.

> [Dev-discussion, so kept posted here.]
>
> I've not seen this question come up yet, so I'll raise it.
>
> Shouldn't the question really depend on whether optional dependencies are
> pulled in by the protocols or not? If everything's pidgin internal, then
> if upstream wants all the protocols on as shipped, I think that's the
> sane thing to do.
>
> 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.

>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.

Once again thank you for your time,
Eric


> --
> 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

On Thursday 19 July 2007, Duncan wrote:
> 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.

USE flags are not for controlling dependencies, they are for controlling
features. it just happens to work out that most of the time, features imply
dependencies.
-mike

"Eric Polino" <aluink@gmail.com> 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... <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

--
gentoo-dev@gentoo.org mailing list

On 7/19/07, Duncan <1i5t5.duncan@cox.net> wrote:
> "Eric Polino" <aluink@gmail.com> 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... <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
>
> --
> 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

"Eric Polino" <aluink@gmail.com> posted
b21328ed0707192102s2d4d46c8t719e2e4b9720967f@mail.gmail.com, excerpted
below, on Fri, 20 Jul 2007 00:02:56 -0400:

> On 7/19/07, Duncan <1i5t5.duncan@cox.net> wrote:
>> "Eric Polino" <aluink@gmail.com> posted
>> b21328ed0707191852o3ec406b6ga325c70951d83adc@mail.gmail.com, excerpted
>> below, on Thu, 19 Jul 2007 21:52:16 -0400:
>>
>> > Yes there would be a few other small supporting packages.
>>
>> 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.

Some people don't like negative USE flags because they are a bit counter-
intuitive. You /enable/ the USE flag to /disable/ the feature, and that
counter-intuitivity has some devs hoping to eventually do away with them
entirely. Personally, while I generally prefer positive flags, negative
flags serve a very good purpose precisely because they /do/ stick out --
if I encounter one, it's a pretty good indication I better think twice
about disabling it (since it's generally enabled by default). It serves
as a quite useful distinction between "do as you wish" flags and "do as
you wish, but be SURE you know the consequences first."

So I agree with you on the negative USE flag idea but believe many won't.

The security issue is in general, and worse when an app is net-exposed as
is the case here. Think of the recent aim:// protocol exploits in
certain apps. If a user never uses AIM, they may not realize they are
vulnerable, yet if these apps are installed with aim:// protocol active,
they are /very/ exposed as the exploit (from what I've read) required
simply that the remote end of the conversation invoke an aim:// URL with
the malware payload attached.

If it's possible to protect a user from that sort of exploit by making
various protocols optional so they don't need them enabled when not
necessary (and that's what Gentoo does with USE flags and compile from
source), I believe it's a very good idea to do so.

>> To be clear, if it's simply the USE flag defaults under debate, not a
>> problem [but s]omeone mentioned just killing the USE flags and making
>> them all hard dependencies
>
> [H]ow different would this be to any application that requires
> dependencies and you can't change the fact that they require them.

Required are required. Take it or leave it. Decision made by upstream
and when a user chooses that app. Optionals are just that, optional.

> The Pidgin team "sells" their application as having all these protocols
> so they should be there, at least out of the box.

But a big selling point of Gentoo is that it doesn't force you to take
that "box" as it's normally shipped. You effectively get the components
as a kit and assemble it yourself, with the ability to leave out parts
that you don't need. That's a /good/ thing, at least to most Gentoo
users, or by definition, they'd be using a distribution that comes with
all those binaries "pre-assembled". To then ship it with all those
options forced on... goes against one of the big points of running Gentoo
in the first place.

>> People not running -pv or -av... <content for project or user omitted>
>
> Don't know what you mean here.

Simply that I down that down that topic lays a rant, and this isn't the
place for it.

This subthread is headed off-topic for gentoo-dev too, so I'm x-posting
to gentoo-project, with further replies set to go there (if the listserv
doesn't overwrite them). Or reply to me personally if you prefer.

--
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

Eric Polino wrote:
> 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.

The negative (or no*) USE flags are generally considered a "bad thing". They're
"icky".

--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Installer + x86 release coordinator
--
gentoo-dev@gentoo.org mailing list

On 7/20/07, Andrew Gaffney <agaffney@gentoo.org> wrote:
> Eric Polino wrote:
> > 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.
>
> The negative (or no*) USE flags are generally considered a "bad thing". They're
> "icky".

I know and understand that. Though we still have to consider them as
a possible solution to this problem.

> --
> Andrew Gaffney http://dev.gentoo.org/~agaffney/
> Gentoo Linux Developer Catalyst/Installer + x86 release coordinator
> --
> 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