| 1 |
Jim Ramsay wrote: |
| 2 |
>> > This meets the following goals: |
| 3 |
>> > 1) It makes it easy for "regular" users to get netscape-flash with |
| 4 |
>> > any additions required by any global USE flags in exactly one step: |
| 5 |
>> > - emerge netscape-flash |
| 6 |
>> So, in netscape-flash: |
| 7 |
>> RDEPEND=" |
| 8 |
>> ssl? ( foo/libflashsupport ) |
| 9 |
>> pulseaudio? ( foo/libflashsupport ) |
| 10 |
>> esd? ( foo/libflashsupport ) |
| 11 |
>> oss? ( foo/libflashsupport ) |
| 12 |
>> " |
| 13 |
>> and IUSE="ssl pulseaudio esd oss gnutls" in libflashsupport (which, as |
| 14 |
>> already said, has it's own ebuild)? |
| 15 |
> |
| 16 |
> Yes, I considered this, it is option (2) in the original post in this |
| 17 |
> thread. However, I do not believe this is the best solution. Consider |
| 18 |
> the case where: |
| 19 |
> - A user has 'ssl' disabled globally |
| 20 |
> - A user sees that netscape-flash now has 'ssl' support, so he/she |
| 21 |
> enables 'ssl' just for the netscape-flash ebuild. |
| 22 |
> - The ebuild would then install libflashsupport, but do so without |
| 23 |
> actually adding ssl support, which would be quite frustrating to the |
| 24 |
> user, and probably generate unnedded bug traffic. |
| 25 |
> |
| 26 |
Well then the ebuild for libflashsupport should pull in ssl iff the flag is |
| 27 |
set; other packages do similar stuff. A usr who adds ssl to package.use |
| 28 |
will not be surprised to see the ssl package being pulled in, so no bad |
| 29 |
experience for the usr, and hopefully less bug reports. |
| 30 |
|
| 31 |
I really *don't* like the option of a crippled install. It's |
| 32 |
counter-intuitive and is asking for trouble imo. |
| 33 |
|
| 34 |
Thanks for adding shiny stuff to flash :) |
| 35 |
|
| 36 |
|
| 37 |
-- |
| 38 |
gentoo-dev@g.o mailing list |
Archives