when to use a function and an implementation use flag.
On Sat, Mar 27, 2010 at 11:06 PM, Doug Goldstein <email@example.com> wrote:
> On Sat, Mar 27, 2010 at 9:44 AM, Petteri Räty <firstname.lastname@example.org> wrote:
>> On 03/24/2010 08:30 PM, Peter Hjalmarsson wrote:
>>> For qemu-kvm the problem is that there is only one implementation (i.e.
>>> gnutls), and if I want to have ssl support I have to enable gnutls for
>>> this package.
>> In this case the ebuild should have only ssl use flag.
>>> When I wrote a bug about this I got a rather short reply from maintainer
>>> about pointing me to the policy about this.
>> Where did he point you to?
> I didn't point him anywhere. I merely asked him for a policy on this.
> Because senseless changes in USE flags will require my 9 VM servers
> will need to be tweaked around for a pointless USE flag change and I
> don't need administrative burden for the sake of administrative
I have concerns with this which I will attempt to summarize below.
1) Traditional binary distributions have releases that take users over
these changes (dist-upgrade and similar processes.)
2) Gentoo has no releases, so 'annoying administrative changes' are
certainly more challenging, because it is difficult to apply them to
new machines and not old ones.
3) Cleanup changes such as the one proposed are good for the health of
Gentoo. Consistency in flags actually makes it *easier* for users to
configure their systems. Consistency in ebuild behavior makes it
*easier* developers to maintain ebuilds.
4) Not making changes because they may affect existing systems is
crap. It holds the distribution back because everyone will always
pull this card out to veto major changes.
It would be interesting if we could make these changes less painful:
1) For this change, attempt to detect how users are using these flags
and migrate them to the new system. This will likely be easy for the
80% case (/etc/portage/...) and hard for the 20% case (cross-compiles,
and other odd things involving ROOT.)
2) Defer changes like this to some kind of release date. Write down
what you want to do somewhere. At the prescribed time (once a [month,
year, quarter?]) apply all the changes to the tree and release GLEP 42
news items, changelogs, webpage stuff, forums posts, etc.
3) other crap I haven't thought of.
>>> So I have a question:
>>> Is there no policy about this?
>> The policy is that USE="ssl" controls whether to enable ssl support in
>> general. Then the specific use flags like gnutls and openssl control
>> what implementation to use if the package supports multiple.
> Again, this policy is stated but no one can point me to anything. The
> closest thing to a "policy" is you sending a follow up e-mail to the
> dev list to make this a policy.
> Doug Goldstein