| 1 |
El lun, 02-03-2015 a las 00:02 -0500, Tim Harder escribió: |
| 2 |
> The next council meeting will be on March 10th, 19:00 UTC in |
| 3 |
> #gentoo-council on Freenode. |
| 4 |
> |
| 5 |
> Please respond to this message on the gentoo-project list with any |
| 6 |
> agenda items you want to propose or discuss. |
| 7 |
> |
| 8 |
> Thanks, |
| 9 |
> Tim |
| 10 |
|
| 11 |
And finally: |
| 12 |
http://archives.gentoo.org/gentoo-dev/message/5c127aed355ee19d15ac38e114097f74 |
| 13 |
|
| 14 |
This is a bit older, but nothing has changed since that and the current |
| 15 |
"incoherent" situation is still the same. The main issue are: |
| 16 |
- Depending on the desktop, the approach that ends up enabling/disabling |
| 17 |
keyring support is different. |
| 18 |
- Users are currently forced to know in some cases that they need to, |
| 19 |
for example, enable "libsecret" to have keyring support, and I don't see |
| 20 |
it so intuitive (also, if it's renamed again, users will need to know |
| 21 |
the new name/USE to keep the same behavior of having keyring support). |
| 22 |
|
| 23 |
In the mail thread there are several suggestions to unify this. The one |
| 24 |
I personally prefer is to USE a global "keyring" USE flag for packages |
| 25 |
only having that support via one of the options and use keyring+gnome or |
| 26 |
keyring+kde if we need to choose between the keyring implementation for |
| 27 |
gnome or kde (or the desktop that could have its own lib or tool for |
| 28 |
this) |
| 29 |
|
| 30 |
Thanks a lot |
Archives