Mailing List Archive

Jim Ramsay wrote:
>
> 1) Create a single local USE flag (flashsupport or something) that will
> just pull in this dependency.
>
> 2) Use the same set of USE flags as libflashsupport has, with any of
> them adding libflashsupport to the dep list, since these are all global
> flags and will most likely be enabled for both netscape-flash and
> libflashsupport
>
> I'm personally thinking (1) is the better of the 2 options, but I'd
> like to know if anyone has any other wondrous solutions to this.

Does/will anything else dep on flashsupport? If not, why not just add
the USE flags to netscape-flash and install libflashsupport as part of
the netscape-flash install instead of a separate package.
--
gentoo-dev@gentoo.org mailing list

On Thu, 2007-10-05 at 14:20 -0400, Patrick McLean wrote:
> Jim Ramsay wrote:
> >
> > 1) Create a single local USE flag (flashsupport or something) that will
> > just pull in this dependency.
> >
> > 2) Use the same set of USE flags as libflashsupport has, with any of
> > them adding libflashsupport to the dep list, since these are all global
> > flags and will most likely be enabled for both netscape-flash and
> > libflashsupport
> >
> > I'm personally thinking (1) is the better of the 2 options, but I'd
> > like to know if anyone has any other wondrous solutions to this.
>
> Does/will anything else dep on flashsupport? If not, why not just add
> the USE flags to netscape-flash and install libflashsupport as part of
> the netscape-flash install instead of a separate package.

If its a separate package that will be updated separately, then it
doesn't make sense to put it in the separate package and I support
option 1. Otherwise, if they'll always be together, then just put it in
the same package.

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

Olivier Crête wrote:
> On Thu, 2007-10-05 at 14:20 -0400, Patrick McLean wrote:
> > Jim Ramsay wrote:
> > >
> > > 1) Create a single local USE flag (flashsupport or something)
> > > that will just pull in this dependency.
> > >
> > > 2) Use the same set of USE flags as libflashsupport has, with any
> > > of them adding libflashsupport to the dep list, since these are
> > > all global flags and will most likely be enabled for both
> > > netscape-flash and libflashsupport
> > >
> > > I'm personally thinking (1) is the better of the 2 options, but
> > > I'd like to know if anyone has any other wondrous solutions to
> > > this.
> >
> > Does/will anything else dep on flashsupport? If not, why not just
> > add the USE flags to netscape-flash and install libflashsupport as
> > part of the netscape-flash install instead of a separate package.
>
> If its a separate package that will be updated separately, then it
> doesn't make sense to put it in the separate package and I support
> option 1. Otherwise, if they'll always be together, then just put it
> in the same package.

Yes, libflashsupport is distributed separately and is on a different
release schedule than netscape-flash.

I suppose I could also propose:

4) netscape-flash just RDEPENDS on libflashsupport all the time. It's
certainly not a large library to be added on.

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

Jim Ramsay wrote:
> Olivier Crête wrote:
>> On Thu, 2007-10-05 at 14:20 -0400, Patrick McLean wrote:
>>> Jim Ramsay wrote:
>>>> 1) Create a single local USE flag (flashsupport or something)
>>>> that will just pull in this dependency.
>>>>
>>>> 2) Use the same set of USE flags as libflashsupport has, with any
>>>> of them adding libflashsupport to the dep list, since these are
>>>> all global flags and will most likely be enabled for both
>>>> netscape-flash and libflashsupport
>>>>
>>>> I'm personally thinking (1) is the better of the 2 options, but
>>>> I'd like to know if anyone has any other wondrous solutions to
>>>> this.
>>> Does/will anything else dep on flashsupport? If not, why not just
>>> add the USE flags to netscape-flash and install libflashsupport as
>>> part of the netscape-flash install instead of a separate package.
>> If its a separate package that will be updated separately, then it
>> doesn't make sense to put it in the separate package and I support
>> option 1. Otherwise, if they'll always be together, then just put it
>> in the same package.
>
> Yes, libflashsupport is distributed separately and is on a different
> release schedule than netscape-flash.
>
> I suppose I could also propose:
>
> 4) netscape-flash just RDEPENDS on libflashsupport all the time. It's
> certainly not a large library to be added on.
>

That is a terrible idea. Don't make it "depend" on something that it
clearly does *not* depend on. Flash works just fine without the optional
add-ons, and those are *definitely* optional. I've never needed
libflashsupport and would prefer not seeing useless cruft attached to a
perfectly working Flash installation.

If you're going to add it to USE, then make sure it's *not* on by
default, thanks.

Josh Saddler wrote:
> Jim Ramsay wrote:
> > I suppose I could also propose:
> >
> > 4) netscape-flash just RDEPENDS on libflashsupport all the time.
> > It's certainly not a large library to be added on.
> >
>
> That is a terrible idea. Don't make it "depend" on something that it
> clearly does *not* depend on. Flash works just fine without the
> optional add-ons, and those are *definitely* optional. I've never
> needed libflashsupport and would prefer not seeing useless cruft
> attached to a perfectly working Flash installation.

Point taken - If you don't want the extra features you don't want
libflashsupport at all.

I could make it so that if all of the USE flags for libflashsupport are
turned off it doesn't actually install the library at all, just gets
added to the list of installed packages.

> If you're going to add it to USE, then make sure it's *not* on by
> default, thanks.

This way it will adhere to your current set of global USE flags. If you
have pulseaudio, esd, oss, ssl, or gnutls on globally, it will install
libflashsupport with the appropriate hooks in it. If they are all
off (either globally or specifically for libflashsupport) you will
just get the same old netscape-flash with no add-ons.

Is this a worthy compromise?

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

On Fri, 2007-11-05 at 12:12 -0600, Jim Ramsay wrote:
> Josh Saddler wrote:
> > Jim Ramsay wrote:
> > > I suppose I could also propose:
> > >
> > > 4) netscape-flash just RDEPENDS on libflashsupport all the time.
> > > It's certainly not a large library to be added on.
> > >
> >
> > That is a terrible idea. Don't make it "depend" on something that it
> > clearly does *not* depend on. Flash works just fine without the
> > optional add-ons, and those are *definitely* optional. I've never
> > needed libflashsupport and would prefer not seeing useless cruft
> > attached to a perfectly working Flash installation.
>
> Point taken - If you don't want the extra features you don't want
> libflashsupport at all.
>
> I could make it so that if all of the USE flags for libflashsupport are
> turned off it doesn't actually install the library at all, just gets
> added to the list of installed packages.
>
> > If you're going to add it to USE, then make sure it's *not* on by
> > default, thanks.
>
> This way it will adhere to your current set of global USE flags. If you
> have pulseaudio, esd, oss, ssl, or gnutls on globally, it will install
> libflashsupport with the appropriate hooks in it. If they are all
> off (either globally or specifically for libflashsupport) you will
> just get the same old netscape-flash with no add-ons.
>
> Is this a worthy compromise?

This seems even worse.. I think either having one local use flag in
netscape-flash is probably the best solution.. The second best is to
have all of the use flags and RDEPEND on flash-support if any is
enabled.

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

Olivier Crête wrote:
> On Fri, 2007-11-05 at 12:12 -0600, Jim Ramsay wrote:
> > Josh Saddler wrote:
> > > Jim Ramsay wrote:
> > > > I suppose I could also propose:
> > > >
> > > > 4) netscape-flash just RDEPENDS on libflashsupport all the time.
> > > > It's certainly not a large library to be added on.
> > > >
> > >
> > > That is a terrible idea. Don't make it "depend" on something that
> > > it clearly does *not* depend on. Flash works just fine without the
> > > optional add-ons, and those are *definitely* optional. I've never
> > > needed libflashsupport and would prefer not seeing useless cruft
> > > attached to a perfectly working Flash installation.
> >
> > Point taken - If you don't want the extra features you don't want
> > libflashsupport at all.
> >
> > I could make it so that if all of the USE flags for libflashsupport
> > are turned off it doesn't actually install the library at all, just
> > gets added to the list of installed packages.
> >
> > > If you're going to add it to USE, then make sure it's *not* on by
> > > default, thanks.
> >
> > This way it will adhere to your current set of global USE flags. If
> > you have pulseaudio, esd, oss, ssl, or gnutls on globally, it will
> > install libflashsupport with the appropriate hooks in it. If they
> > are all off (either globally or specifically for libflashsupport)
> > you will just get the same old netscape-flash with no add-ons.
> >
> > Is this a worthy compromise?
>
> This seems even worse.. I think either having one local use flag in
> netscape-flash is probably the best solution.. The second best is to
> have all of the use flags and RDEPEND on flash-support if any is
> enabled.

Can you explain what you mean by "even worse"? I think my latest
solution is more correct than any of the others yet proposed. In fact,
here's another small improvement on it:

Have netscape-flash with IUSE="vanilla" (by default it is off), which
when enabled will not pull in libflashsupport.

This meets the following goals:

1) It makes it easy for "regular" users to get netscape-flash with any
additions required by any global USE flags in exactly one step:
- emerge netscape-flash
This is my #1 goal, otherwise I'd just have 'libflashsupport' as its
own separate package and those "in the know" would install it
separately if they want any of the extra features. But users should not
have to have special knowledge to get the features they have already
enabled in their global USE flags.

2) It makes it easy for "power" users to not have libflashsupport
actually install anything by disabling all the USE flags. This will
take 3 steps:
- Notice at upgrade or install time that there's this new 'extra'
package being installed
- Enable the 'vanilla' flag for netscape-flash
- Continue with upgrade or install

Also, having all of the ssl/gnutls/pulseaudio/esd/oss flags turned off
for libflashsupport will have the effect of not actually installing the
library, so the only added cost there is one more entry in the list of
installed packages, which I hope you will agree is basically zero.

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

On Fri, 2007-11-05 at 13:19 -0600, Jim Ramsay wrote:
> Olivier Crête wrote:
> > On Fri, 2007-11-05 at 12:12 -0600, Jim Ramsay wrote:
> > > Josh Saddler wrote:
> > > > Jim Ramsay wrote:
> > > > > I suppose I could also propose:
> > > > >
> > > > > 4) netscape-flash just RDEPENDS on libflashsupport all the time.
> > > > > It's certainly not a large library to be added on.
> > > > >
> > > >
> > > > That is a terrible idea. Don't make it "depend" on something that
> > > > it clearly does *not* depend on. Flash works just fine without the
> > > > optional add-ons, and those are *definitely* optional. I've never
> > > > needed libflashsupport and would prefer not seeing useless cruft
> > > > attached to a perfectly working Flash installation.
> > >
> > > Point taken - If you don't want the extra features you don't want
> > > libflashsupport at all.
> > >
> > > I could make it so that if all of the USE flags for libflashsupport
> > > are turned off it doesn't actually install the library at all, just
> > > gets added to the list of installed packages.
> > >
> > > > If you're going to add it to USE, then make sure it's *not* on by
> > > > default, thanks.
> > >
> > > This way it will adhere to your current set of global USE flags. If
> > > you have pulseaudio, esd, oss, ssl, or gnutls on globally, it will
> > > install libflashsupport with the appropriate hooks in it. If they
> > > are all off (either globally or specifically for libflashsupport)
> > > you will just get the same old netscape-flash with no add-ons.
> > >
> > > Is this a worthy compromise?
> >
> > This seems even worse.. I think either having one local use flag in
> > netscape-flash is probably the best solution.. The second best is to
> > have all of the use flags and RDEPEND on flash-support if any is
> > enabled.
>
> Can you explain what you mean by "even worse"? I think my latest
> solution is more correct than any of the others yet proposed. In fact,
> here's another small improvement on it:
>
> Have netscape-flash with IUSE="vanilla" (by default it is off), which
> when enabled will not pull in libflashsupport.

flashsupport should be disabled by default. I still think you should add
a positive use flag to netscape-flash (call it flashsupport or or a
combination of esd/ssl/gnutls/etc).

> This meets the following goals:
>
> 1) It makes it easy for "regular" users to get netscape-flash with any
> additions required by any global USE flags in exactly one step:
> - emerge netscape-flash
> This is my #1 goal, otherwise I'd just have 'libflashsupport' as its
> own separate package and those "in the know" would install it
> separately if they want any of the extra features. But users should not
> have to have special knowledge to get the features they have already
> enabled in their global USE flags.
>
> 2) It makes it easy for "power" users to not have libflashsupport
> actually install anything by disabling all the USE flags. This will
> take 3 steps:
> - Notice at upgrade or install time that there's this new 'extra'
> package being installed
> - Enable the 'vanilla' flag for netscape-flash
> - Continue with upgrade or install
>
> Also, having all of the ssl/gnutls/pulseaudio/esd/oss flags turned off
> for libflashsupport will have the effect of not actually installing the
> library, so the only added cost there is one more entry in the list of
> installed packages, which I hope you will agree is basically zero.

Installing a package without really installing it is EVIL. The db should
represent whats installed on the system, otherwise it will become very
very confusion for users.

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

Hi,

Jim Ramsay wrote:
> [snip]
> Have netscape-flash with IUSE="vanilla" (by default it is off), which
> when enabled will not pull in libflashsupport.
>

I don't quite see why this is necessary? Or why you do have this discussion?

> This meets the following goals:
>
> 1) It makes it easy for "regular" users to get netscape-flash with any
> additions required by any global USE flags in exactly one step:
> - emerge netscape-flash
>

So, in netscape-flash:
RDEPEND="
ssl? ( foo/libflashsupport )
pulseaudio? ( foo/libflashsupport )
esd? ( foo/libflashsupport )
oss? ( foo/libflashsupport )
"
and IUSE="ssl pulseaudio esd oss gnutls" in libflashsupport (which, as
already said, has it's own ebuild)?

> 2) It makes it easy for "power" users to not have libflashsupport
> actually install anything by disabling all the USE flags. This will
> take 3 steps:
> - Notice at upgrade or install time that there's this new 'extra'
> package being installed
> - Enable the 'vanilla' flag for netscape-flash
> - Continue with upgrade or install
>

It's still easy enough to disable it via -* in package.use?

Regards,
Thomas
--
gentoo-dev@gentoo.org mailing list

Thomas Rösner wrote:
> Jim Ramsay wrote:
> > [snip]
> > Have netscape-flash with IUSE="vanilla" (by default it is off),
> > which when enabled will not pull in libflashsupport.
> >
>
> I don't quite see why this is necessary? Or why you do have this
> discussion?

I started this discussion to find out the best way to add
libflashsupport to netscape-flash for users who want the extra features
that it offers.

> > This meets the following goals:
> >
> > 1) It makes it easy for "regular" users to get netscape-flash with
> > any additions required by any global USE flags in exactly one step:
> > - emerge netscape-flash
> >
>
> So, in netscape-flash:
> RDEPEND="
> ssl? ( foo/libflashsupport )
> pulseaudio? ( foo/libflashsupport )
> esd? ( foo/libflashsupport )
> oss? ( foo/libflashsupport )
> "
> and IUSE="ssl pulseaudio esd oss gnutls" in libflashsupport (which, as
> already said, has it's own ebuild)?

Yes, I considered this, it is option (2) in the original post in this
thread. However, I do not believe this is the best solution. Consider
the case where:
- A user has 'ssl' disabled globally
- A user sees that netscape-flash now has 'ssl' support, so he/she
enables 'ssl' just for the netscape-flash ebuild.
- The ebuild would then install libflashsupport, but do so without
actually adding ssl support, which would be quite frustrating to the
user, and probably generate unnedded bug traffic.

It would be much more clear to only use the ssl USE flag when it
actually affects ssl support.

> > 2) It makes it easy for "power" users to not have libflashsupport
> > actually install anything by disabling all the USE flags. This will
> > take 3 steps:
> > - Notice at upgrade or install time that there's this new 'extra'
> > package being installed
> > - Enable the 'vanilla' flag for netscape-flash
> > - Continue with upgrade or install
>
> It's still easy enough to disable it via -* in package.use?

I'm not sure I understand what you are saying here.

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

Olivier Crête wrote:
> On Fri, 2007-11-05 at 13:19 -0600, Jim Ramsay wrote:
> > Olivier Crête wrote:
> > > On Fri, 2007-11-05 at 12:12 -0600, Jim Ramsay wrote:
> > > > Josh Saddler wrote:
> > > > > Jim Ramsay wrote:
> > > > > > I suppose I could also propose:
> > > > > >
> > > > > > 4) netscape-flash just RDEPENDS on libflashsupport all the
> > > > > > time. It's certainly not a large library to be added on.
> > > > > >
> > > > >
> > > > > That is a terrible idea. Don't make it "depend" on something
> > > > > that it clearly does *not* depend on. Flash works just fine
> > > > > without the optional add-ons, and those are *definitely*
> > > > > optional. I've never needed libflashsupport and would prefer
> > > > > not seeing useless cruft attached to a perfectly working
> > > > > Flash installation.
> > > >
> > > > Point taken - If you don't want the extra features you don't
> > > > want libflashsupport at all.
> > > >
> > > > I could make it so that if all of the USE flags for
> > > > libflashsupport are turned off it doesn't actually install the
> > > > library at all, just gets added to the list of installed
> > > > packages.
> > > >
> > > > > If you're going to add it to USE, then make sure it's *not*
> > > > > on by default, thanks.
> > > >
> > > > This way it will adhere to your current set of global USE
> > > > flags. If you have pulseaudio, esd, oss, ssl, or gnutls on
> > > > globally, it will install libflashsupport with the appropriate
> > > > hooks in it. If they are all off (either globally or
> > > > specifically for libflashsupport) you will just get the same
> > > > old netscape-flash with no add-ons.
> > > >
> > > > Is this a worthy compromise?
> > >
> > > This seems even worse.. I think either having one local use flag
> > > in netscape-flash is probably the best solution.. The second best
> > > is to have all of the use flags and RDEPEND on flash-support if
> > > any is enabled.
> >
> > Can you explain what you mean by "even worse"? I think my latest
> > solution is more correct than any of the others yet proposed. In
> > fact, here's another small improvement on it:
> >
> > Have netscape-flash with IUSE="vanilla" (by default it is off),
> > which when enabled will not pull in libflashsupport.
>
> flashsupport should be disabled by default. I still think you should
> add a positive use flag to netscape-flash (call it flashsupport or or
> a combination of esd/ssl/gnutls/etc).

I disagree with you here. I believe it should be installed by default
because it would then install by default any optional features that
a user has enabled in his/her global USE flags. Which I argue is the
expected outcome of installing any package.

I guess I still don't see what the benefit would be of having it
disabled by default - It would just be making more work for users who
want the added features. If you have a compelling argument for your
side that I'm not seeing, please let me know what it is.

> > This meets the following goals:
> >
> > 1) It makes it easy for "regular" users to get netscape-flash with
> > any additions required by any global USE flags in exactly one step:
> > - emerge netscape-flash
> > This is my #1 goal, otherwise I'd just have 'libflashsupport' as its
> > own separate package and those "in the know" would install it
> > separately if they want any of the extra features. But users should
> > not have to have special knowledge to get the features they have
> > already enabled in their global USE flags.
> >
> > 2) It makes it easy for "power" users to not have libflashsupport
> > actually install anything by disabling all the USE flags. This will
> > take 3 steps:
> > - Notice at upgrade or install time that there's this new 'extra'
> > package being installed
> > - Enable the 'vanilla' flag for netscape-flash
> > - Continue with upgrade or install
> >
> > Also, having all of the ssl/gnutls/pulseaudio/esd/oss flags turned
> > off for libflashsupport will have the effect of not actually
> > installing the library, so the only added cost there is one more
> > entry in the list of installed packages, which I hope you will
> > agree is basically zero.
>
> Installing a package without really installing it is EVIL. The db
> should represent whats installed on the system, otherwise it will
> become very very confusion for users.

Well, I was actually going to have it install a single README file
explaining why the package didn't install very much. I could of
course leave in the 'libflashsupport.so' library that would basically do
nothing... Really, this is just a shortcut so that if you don't want any
of the features libflashsupport provides you will not have the small
overhead of having the plugin load libflashsupport.so when it starts up.

For added information, here is what I understand happens when you load
the existing Adobe flash plugin:

- Check for a plugin called /usr/lib/libflashsupport.so
- If found, load it, and use any of the functions provided there to
support alternate audio, video, or ssl features.
- If not found, carry on and use the default set of features: ALSA
sound output and no SSL support.

So the possibilities for people not wanting the added features are:
- Have no such file called /usr/lib/libflashsupport.so
- Have this library, but do not have it supply any functions. I think
this is less desirable than just not installing libflashsupport.so

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

On Fri, 2007-11-05 at 13:52 -0600, Jim Ramsay wrote:
> Thomas Rösner wrote:
> > Jim Ramsay wrote:
> > > [snip]
> > > Have netscape-flash with IUSE="vanilla" (by default it is off),
> > > which when enabled will not pull in libflashsupport.
> > >
> >
> > I don't quite see why this is necessary? Or why you do have this
> > discussion?
>
> I started this discussion to find out the best way to add
> libflashsupport to netscape-flash for users who want the extra features
> that it offers.
>
> > > This meets the following goals:
> > >
> > > 1) It makes it easy for "regular" users to get netscape-flash with
> > > any additions required by any global USE flags in exactly one step:
> > > - emerge netscape-flash
> > >
> >
> > So, in netscape-flash:
> > RDEPEND="
> > ssl? ( foo/libflashsupport )
> > pulseaudio? ( foo/libflashsupport )
> > esd? ( foo/libflashsupport )
> > oss? ( foo/libflashsupport )
> > "
> > and IUSE="ssl pulseaudio esd oss gnutls" in libflashsupport (which, as
> > already said, has it's own ebuild)?
>
> Yes, I considered this, it is option (2) in the original post in this
> thread. However, I do not believe this is the best solution. Consider
> the case where:
> - A user has 'ssl' disabled globally
> - A user sees that netscape-flash now has 'ssl' support, so he/she
> enables 'ssl' just for the netscape-flash ebuild.
> - The ebuild would then install libflashsupport, but do so without
> actually adding ssl support, which would be quite frustrating to the
> user, and probably generate unnedded bug traffic.
>
> It would be much more clear to only use the ssl USE flag when it
> actually affects ssl support.

The solution to this is use-based deps.. The short term workaround is to
use built_with_use.

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

Ryan Hill wrote:
> net-www/netscape-flash-9.0.31.0 USE="libflashsupport -debug"
> media-lib/libflashsupport-1.2 USE="esd gnutls oss pulseaudio ssl"
>
> is the right way to do it.

Absolutely! I was about to post the same thing -- put some kind of use
on netscape-flash to pull in libflashsupport if desired, and then just
keep the standard USE flags on libflashsupport to setup the kind of
functionality wanted by the user.

Forcing a depend on libflashsupport unconditionally is just plain
stupid; there is no possible justification for it. netscape-flash has
gone without such silly dependencies for some time, as it really does
work just fine without them. :)

(FWIW, I've never needed any kind of weird extra functionality not found
in Flash itself; OSS and ESD are both the spawn of the devil!)

Jim Ramsay wrote:

> This libflashsupport-1.2 will have the following use flags:
>
> pulseaudio oss esd ssl gnutls
>
> Now, I was thinking that it would be much easier for users if
> the netscape-flash ebuild automatically pulled this in, and was
> wondering the best way to do this. I have 2 ideas:
>
> 1) Create a single local USE flag (flashsupport or something) that will
> just pull in this dependency.
>
> 2) Use the same set of USE flags as libflashsupport has, with any of
> them adding libflashsupport to the dep list, since these are all global
> flags and will most likely be enabled for both netscape-flash and
> libflashsupport
>
> I'm personally thinking (1) is the better of the 2 options, but I'd
> like to know if anyone has any other wondrous solutions to this.

net-www/netscape-flash-9.0.31.0 USE="libflashsupport -debug"
media-lib/libflashsupport-1.2 USE="esd gnutls oss pulseaudio ssl"

is the right way to do it.

--
where to now? if i had to guess
dirtyepic gentoo org i'm afraid to say antarctica's next
9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8)

--
gentoo-dev@gentoo.org mailing list

Jim Ramsay wrote:
>> > This meets the following goals:
>> > 1) It makes it easy for "regular" users to get netscape-flash with
>> > any additions required by any global USE flags in exactly one step:
>> > - emerge netscape-flash
>> So, in netscape-flash:
>> RDEPEND="
>> ssl? ( foo/libflashsupport )
>> pulseaudio? ( foo/libflashsupport )
>> esd? ( foo/libflashsupport )
>> oss? ( foo/libflashsupport )
>> "
>> and IUSE="ssl pulseaudio esd oss gnutls" in libflashsupport (which, as
>> already said, has it's own ebuild)?
>
> Yes, I considered this, it is option (2) in the original post in this
> thread. However, I do not believe this is the best solution. Consider
> the case where:
> - A user has 'ssl' disabled globally
> - A user sees that netscape-flash now has 'ssl' support, so he/she
> enables 'ssl' just for the netscape-flash ebuild.
> - The ebuild would then install libflashsupport, but do so without
> actually adding ssl support, which would be quite frustrating to the
> user, and probably generate unnedded bug traffic.
>
Well then the ebuild for libflashsupport should pull in ssl iff the flag is
set; other packages do similar stuff. A usr who adds ssl to package.use
will not be surprised to see the ssl package being pulled in, so no bad
experience for the usr, and hopefully less bug reports.

I really *don't* like the option of a crippled install. It's
counter-intuitive and is asking for trouble imo.

Thanks for adding shiny stuff to flash :)


--
gentoo-dev@gentoo.org mailing list