| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On Thursday 29 January 2004 10:31, Robin H. Johnson wrote: |
| 5 |
> I'm sorry, but that is wrong, for several reasons. While it is |
| 6 |
> definetly true that packages shouldn't have hardcoded numeric uid/gid |
| 7 |
> in the package, actually really do want specific numeric uid/gid in |
| 8 |
> the ebuilds, or somewhere within the control of the distribution. The |
| 9 |
> simplest of cases for this is GRP. For example: Take qmail as a |
| 10 |
> package, and say it's users weren't already in baselayout (where they |
| 11 |
> are presently), but rather assigned the next available values when |
| 12 |
> pkg_preinst is done. Tar stores uid/gids numerically as opposed to |
| 13 |
> names, so there is no gaurentee that install accross two systems at |
| 14 |
> different stages will produce a installed package that works. Doing |
| 15 |
> lots of chown calls after the package is merged, while possible, is |
| 16 |
> more of a pain in the posterior than anything else. |
| 17 |
|
| 18 |
This seems a tar problem to me. As tar is actually originally a backup |
| 19 |
tool it is correct behaviour for that. It is however not correct |
| 20 |
behaviour for cross-system functionality. Actually from the tar info |
| 21 |
page it says following: |
| 22 |
|
| 23 |
`--numeric-owner' |
| 24 |
This option will notify `tar' that it should use numeric user and |
| 25 |
group IDs when creating a `tar' file, rather than names. |
| 26 |
|
| 27 |
It seems that names is the default. Else it should be for binary |
| 28 |
packages. |
| 29 |
|
| 30 |
> Another problem case is applications that resolve usernames/groupnames |
| 31 |
> into numeric values at compile time, they also won't take kindly to |
| 32 |
> being moved over systems as compiled packages, when the uid/gid values |
| 33 |
> vary. |
| 34 |
|
| 35 |
Those are the applications I think should be patched. Packages should |
| 36 |
never depend on certain numerical uid's. If they do, they are broken. |
| 37 |
|
| 38 |
> One final case, more for convenience in data recovery than anything |
| 39 |
> else. Say you loose your /etc/passwd and /etc/group due to some reason |
| 40 |
> (filesystem corruption, user error, etc.), but /usr and /var are |
| 41 |
> still intact, distribution constant uid/gid values make recovery a |
| 42 |
> _lot_ easier. |
| 43 |
|
| 44 |
I can agree with that. I think it is no reason though to have a broken |
| 45 |
implementation. It should be configurable which uid a package has. Also |
| 46 |
there are more daemons in the world than there are "special" uid's |
| 47 |
available, so it will not even work correctly in the end. |
| 48 |
|
| 49 |
Basically numbers are only keys by which the kernel identifies users. |
| 50 |
This because numbers are computationally more "nice" than names. In |
| 51 |
normal operation packages should never care about the numbers. They can |
| 52 |
retrieve them when they need to interact with the kernel or for internal |
| 53 |
efficiency, but to assume that the numbers are equal all the time is a |
| 54 |
mistake, just as assuming that users exist in /etc/passwd (why not |
| 55 |
ldap?) and groups in /etc/group. |
| 56 |
|
| 57 |
Paul |
| 58 |
|
| 59 |
- -- |
| 60 |
Paul de Vrieze |
| 61 |
Gentoo Developer |
| 62 |
Mail: pauldv@g.o |
| 63 |
Homepage: http://www.devrieze.net |
| 64 |
-----BEGIN PGP SIGNATURE----- |
| 65 |
Version: GnuPG v1.2.4 (GNU/Linux) |
| 66 |
|
| 67 |
iD8DBQFAGNjcbKx5DBjWFdsRAv6CAJ409SjSD/IzpClJFoQMIgfA1kfWKQCfVRQ3 |
| 68 |
f5mkga1O5HRaM2YvDj64fJg= |
| 69 |
=wuSd |
| 70 |
-----END PGP SIGNATURE----- |
| 71 |
|
| 72 |
-- |
| 73 |
gentoo-dev@g.o mailing list |
Archives