Gentoo Archives: gentoo-dev

From: "William L. Thomson Jr." <wlt-ml@××××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC: Userkit.eclass
Date: Wed, 30 Nov 2016 15:16:31
Message-Id: assp.014214316d.37035730.nyreTDXR3v@wlt
In Reply to: Re: [gentoo-dev] RFC: Userkit.eclass by "Michał Górny"
1 On Wednesday, November 30, 2016 8:54:42 AM EST Michał Górny wrote:
2 > On Tue, 29 Nov 2016 18:13:29 -0500
3 >
4 > "William L. Thomson Jr." <wlt-ml@××××××.com> wrote:
5 >>
6 > > I think you mean enewgroup and enewuser
7 >
8 > FYI, enew* functions handle UID/GID collisions gracefully, and just
9 > fallback to using next free UID/GID.
10
11 I would disagree with such and some what makes specifying a UID/GID pointless
12 if it simply will use the next available in the event of a collision. Which
13 available likely comes from the default allocation range > 500 or 1000. If
14 system and was intended to be below that, not really ideal.
15
16 > I'm not sure if you're aware that but most of tools doing backups
17 > actually use usernames/group names. So does new enough tar. So does
18 > ssh.
19
20 tar can map users and groups via file, but why waste the time with such?
21
22 > Are you specifically using some obsolete or braindead tools to prove
23 > your point? If you don't sync UIDs/GIDs properly, then you don't use
24 > them when moving data across systems. Simple as that.
25
26 I start with consistent base images and have the same uid/gid all on all so
27 syncing is not needed. Nor do I need to deal with it during restoration.
28
29 > The only thing that you could worry about then are missing users/groups
30 > on the target system. But then, so far none of your talk solved that
31 > problem.
32
33 A problem that should not exist with a proper setup.
34
35 --
36 William L. Thomson Jr.

Attachments

File name MIME type
signature.asc application/pgp-signature