| 1 |
On Sat, Jun 20, 2020 at 7:06 PM Daniel Frey <djqfrey@×××××.com> wrote: |
| 2 |
> |
| 3 |
> You just pointed out the ambiguity. |
| 4 |
> |
| 5 |
> Emerging a package solely by its name worked 99.9% of the time before |
| 6 |
> this change. |
| 7 |
> |
| 8 |
> Now new users get the fun of "Gee, which one is the one I actually |
| 9 |
> want?" MythTV is a fairly clear one to figure out, but other packages |
| 10 |
> aren't. |
| 11 |
|
| 12 |
Honestly, your word of "ambiguity" was somewhat ambiguous. I had no |
| 13 |
idea what you were talking about in your original post. :) |
| 14 |
|
| 15 |
I think this is actually a fair criticism. Not so much that it isn't |
| 16 |
clear which one to install, but rather that this system does cause you |
| 17 |
to have to use full cat/pkg atoms when previous pkg alone would have |
| 18 |
worked. There have always been packages where this is necessary, but |
| 19 |
this has made this more common. |
| 20 |
|
| 21 |
I don't think this was really something anybody thought of at the time |
| 22 |
- perhaps somebody might have suggested a tweak at the time if it had |
| 23 |
been. As others have pointed out you could just tweak portage to |
| 24 |
ignore the account category when expanding incomplete atoms to restore |
| 25 |
the previous behavior. |
| 26 |
|
| 27 |
In any case, as to why this system was devised just read: |
| 28 |
https://www.gentoo.org/glep/glep-0081.html |
| 29 |
|
| 30 |
It hasn't been communicated to users much because it tends to have |
| 31 |
little impact on them. Before packages just created accounts when |
| 32 |
needed. Now they pull in an account package that does it instead. If |
| 33 |
the user doesn't care to manage the uids/gids for various accounts |
| 34 |
they don't need to worry about how this works. If they do want to |
| 35 |
manage these themselves they can either create those accounts manually |
| 36 |
beforehand, or override these packages. It is also much more obvious |
| 37 |
when a new package is going to create additional accounts, so users |
| 38 |
who care about such things can intervene before merging the packages. |
| 39 |
|
| 40 |
Overall I'd say it is a net improvement. It of course led to a whole |
| 41 |
bunch of these packages being installed when the change was made, but |
| 42 |
these would generally be no-ops for existing users. |
| 43 |
|
| 44 |
-- |
| 45 |
Rich |
Archives