[gentoo-dev] RFC: changing ssl use flag descriptions and unify behavior

[gentoo-dev] RFC: changing ssl use flag descriptions and unify behavior

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

See this thread for background:
http://archives.gentoo.org/gentoo-dev/msg_0673a33fe75961e510872fd2c1044ced.xml

I think we should go through all the ssl use flag using packages and
unify the use flag descriptions and behavior to the following standing
policy (handed down probably):

1) packages always have the general ssl use flag to control whether to
   enable ssl at all
2) If the package supports multiple backends then there's use flags for
   gnutls, openssl or nss. EAPI 2 use defaults will be used to
   communicate upstream defaults if any. If they are all turned of
   select the default (ssl being on).

No objections and I will open a tracker a week from now and let's see
who joins up to go through packages and open bugs.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] RFC: changing ssl use flag descriptions and unify behavior

[Doug Goldstein]

On Sat, Mar 27, 2010 at 9:54 AM, Petteri Räty <betelgeuse@gentoo.org> wrote:
> See this thread for background:
> http://archives.gentoo.org/gentoo-dev/msg_0673a33fe75961e510872fd2c1044ced.xml
>
> I think we should go through all the ssl use flag using packages and
> unify the use flag descriptions and behavior to the following standing
> policy (handed down probably):
>
> 1) packages always have the general ssl use flag to control whether to
>   enable ssl at all
> 2) If the package supports multiple backends then there's use flags for
>   gnutls, openssl or nss. EAPI 2 use defaults will be used to
>   communicate upstream defaults if any. If they are all turned of
>   select the default (ssl being on).
>
> No objections and I will open a tracker a week from now and let's see
> who joins up to go through packages and open bugs.
>
> Regards,
> Petteri
>
>

I seriously hate changing USE flags for the sake of changing use
flags. This provides a moderate amount of annoyance for anyone that
maintains more then one Gentoo box because they need to then tinker
with their /etc/make.conf and /etc/portage/package.use to get
everything right again. And oh no what if the one box is on ~arch and
one isn't and what if one is x86 and one isn't. Its just such a
configuration nightmare.

So unless there's any real benefit, I'm against this.

Also two little side points... USE defaults happened in EAPI 1. And
the method by which you're asking people to select would be nice if we
had some method for saying USE X and Y are subset of USE A.

-- 
Doug Goldstein

usemove [was Re: [gentoo-dev] RFC: changing ssl use flag descriptions and unify behaviour]

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1856 bytes --]

On Sun, Mar 28, 2010 at 01:03:43AM -0500, Doug Goldstein wrote:
> I seriously hate changing USE flags for the sake of changing use
> flags. This provides a moderate amount of annoyance for anyone that
> maintains more then one Gentoo box because they need to then tinker
> with their /etc/make.conf and /etc/portage/package.use to get
> everything right again. And oh no what if the one box is on ~arch and
> one isn't and what if one is x86 and one isn't. Its just such a
> configuration nightmare.
> 
> So unless there's any real benefit, I'm against this.

I'm not arguing for arbitrary changes, but if the change makes sense 
and isn't trivial it should be done.

What is needed is to tweak the tools for such a move- specifically 
adding a new command to the update machinery (profiles/updates).  
Something roughly like

usemove [atom] original_flag new_flag

If an atom is specified, the move applies only to w/in that pkg; if no 
atom, it's a global shift in the configuration (meaning all ebuilds 
now use gtk instead of gtk2 for example).

Examples:

usemove gtk gtk2
usemove app-admin/gtkrellm gnutls ssl
usemove dev-cpp/sptk:3 gnutls ssl
usemove >=app-editors/emacs-22.3 gzip-el gzip

Etc.

Per the norm for updates, usual rules apply- since it's a string of 
delta commands, once a command is in there it cannot be changed in 
purpose (although folk can tweak existing commands to update for a 
final target, eg: A -> B, B -> C; changing it to A -> C, B -> C).


> Also two little side points... USE defaults happened in EAPI 1. And
> the method by which you're asking people to select would be nice if we
> had some method for saying USE X and Y are subset of USE A.

USE_EXPAND, roughly- I wouldn't say it's fully there, but it certainly 
would be where I'd start for any proposal...

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: usemove [was Re: [gentoo-dev] RFC: changing ssl use flag descriptions and unify behaviour]

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]

On 03/28/2010 09:27 AM, Brian Harring wrote:
> On Sun, Mar 28, 2010 at 01:03:43AM -0500, Doug Goldstein wrote:
>> I seriously hate changing USE flags for the sake of changing use
>> flags. This provides a moderate amount of annoyance for anyone that
>> maintains more then one Gentoo box because they need to then tinker
>> with their /etc/make.conf and /etc/portage/package.use to get
>> everything right again. And oh no what if the one box is on ~arch and
>> one isn't and what if one is x86 and one isn't. Its just such a
>> configuration nightmare.
>>
>> So unless there's any real benefit, I'm against this.
> 
> I'm not arguing for arbitrary changes, but if the change makes sense 
> and isn't trivial it should be done.
> 
> What is needed is to tweak the tools for such a move- specifically 
> adding a new command to the update machinery (profiles/updates).  
> Something roughly like
> 
> usemove [atom] original_flag new_flag
> 
> If an atom is specified, the move applies only to w/in that pkg; if no 
> atom, it's a global shift in the configuration (meaning all ebuilds 
> now use gtk instead of gtk2 for example).
> 

Filed Future EAPI request:
https://bugs.gentoo.org/show_bug.cgi?id=311731

> 
> USE_EXPAND, roughly- I wouldn't say it's fully there, but it certainly 
> would be where I'd start for any proposal...
> 

A good point. So how about renaming gnutls openssl and nss to
ssl_implementation_* to make the usage clear?

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] RFC: changing ssl use flag descriptions and unify behavior

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1396 bytes --]

On Sunday 28 March 2010 02:03:43 Doug Goldstein wrote:
> On Sat, Mar 27, 2010 at 9:54 AM, Petteri Räty wrote:
> > See this thread for background:
> > http://archives.gentoo.org/gentoo-dev/msg_0673a33fe75961e510872fd2c1044ce
> > d.xml
> > 
> > I think we should go through all the ssl use flag using packages and
> > unify the use flag descriptions and behavior to the following standing
> > policy (handed down probably):
> > 
> > 1) packages always have the general ssl use flag to control whether to
> >   enable ssl at all
> > 2) If the package supports multiple backends then there's use flags for
> >   gnutls, openssl or nss. EAPI 2 use defaults will be used to
> >   communicate upstream defaults if any. If they are all turned of
> >   select the default (ssl being on).
> > 
> > No objections and I will open a tracker a week from now and let's see
> > who joins up to go through packages and open bugs.
> 
> I seriously hate changing USE flags for the sake of changing use
> flags.

i dont really think USE=ssl is changing.  it has always been "enable SSL 
support".  unfortunately, because this is usually done via openssl, some 
maintainers thought the flag was the same thing as "use openssl".  so any 
package that is changing is most likely because is currently using USE=ssl 
incorrectly, or not respecting it at all (which is also incorrect).
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]