| 1 |
On 01/27/2017 02:53 PM, Rich Freeman wrote: |
| 2 |
> |
| 3 |
> I'm not saying we can't have random assignment for things where it |
| 4 |
> doesn't matter, or fall back to random assignment, but it seems rather |
| 5 |
> silly to go to all the trouble to have blockers when it would be just |
| 6 |
> as easy to not have a conflict in the first place... |
| 7 |
> |
| 8 |
> Telling users that they can't have postfix and apache on the same box |
| 9 |
> because nobody can be bothered to pick IDs that don't collide seems |
| 10 |
> like an arbitrary imposition. |
| 11 |
|
| 12 |
Agreed, blockers should be a last resort. If neither postfix nor apache |
| 13 |
cares about its UID (they don't), then certainly somebody should change |
| 14 |
one of them. My first impression is that any package that doesn't care |
| 15 |
about its UID should default to "first available", but if that causes |
| 16 |
problems, then that's exactly the sort of use case I'm looking for. |
| 17 |
|
| 18 |
If it's a big problem, we can have devs pick an unclaimed UID and stick |
| 19 |
with it. Or, if there are 5 users total who need the "apache" user to |
| 20 |
have UID 80 across every machine, then it might just make more sense to |
| 21 |
tell them to use an overlay to override sys-user/apache. |
| 22 |
|
| 23 |
Keep in mind that currently, if the UID you want isn't available, |
| 24 |
user.eclass will shrug and give you a different one. No one can really |
| 25 |
rely on consistent UIDs now, but it's not fair to dismiss the idea |
| 26 |
because maybe that's one of the things the GLEP was supposed to fix. |
Archives