| 1 |
On Fri, Jan 27, 2017 at 2:35 PM, Michael Orlitzky <mjo@g.o> wrote: |
| 2 |
> On 01/27/2017 01:52 PM, Rich Freeman wrote: |
| 3 |
>> |
| 4 |
>> This doesn't really seem like a problem though. Just have a table |
| 5 |
>> somewhere (wiki?) to track who is using what UID/GID and encode those |
| 6 |
>> defaults into the ebuild that creates those users. |
| 7 |
>> |
| 8 |
> |
| 9 |
> It should be possible to have two different users with the same UID in |
| 10 |
> the tree, just like we can have two different packages that install the |
| 11 |
> same file. Eventually somebody will notice a file collision, and then we |
| 12 |
> add a blocker per usual. |
| 13 |
> |
| 14 |
|
| 15 |
I'm not saying we can't have random assignment for things where it |
| 16 |
doesn't matter, or fall back to random assignment, but it seems rather |
| 17 |
silly to go to all the trouble to have blockers when it would be just |
| 18 |
as easy to not have a conflict in the first place. Now, if we have |
| 19 |
some longstanding issue from the past that might be another matter, |
| 20 |
but what's wrong with just picking an unused ID (again, for stuff that |
| 21 |
needs it)? |
| 22 |
|
| 23 |
Telling users that they can't have postfix and apache on the same box |
| 24 |
because nobody can be bothered to pick IDs that don't collide seems |
| 25 |
like an arbitrary imposition. Sometimes upstream creates conflicts |
| 26 |
that are just hard to work around (same SONAME, different ABI or even |
| 27 |
API, and so on). And if we were talking about some binary-only |
| 28 |
upstream package that relies on hardcoded UIDs I guess blockers might |
| 29 |
be our only option, and users will just have to be happy that we're |
| 30 |
able to support it at all. However, we shouldn't be the ones creating |
| 31 |
these kinds of conflicts. |
| 32 |
|
| 33 |
-- |
| 34 |
Rich |
Archives