From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id AA9771384B4 for ; Tue, 15 Dec 2015 18:36:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5FBAF21C049; Tue, 15 Dec 2015 18:36:01 +0000 (UTC) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5116521C036 for ; Tue, 15 Dec 2015 18:36:00 +0000 (UTC) Received: by mail-ig0-f175.google.com with SMTP id to18so20519229igc.0 for ; Tue, 15 Dec 2015 10:36:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scriptkitty-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=yH+KDFMkZpDK8/kzdkQ3IueXEtpadmjmK9w1evB4sRA=; b=0vCIxyEamjcgNWM/GWAkCBgUv9ZA3Gx3sdzV+NDA2BGs0KNOzVYqmdo1ZZeBjekx2k HnEwSXClhsHdHVwKcTYslEaNOQbmxj5q6n2n958Ns+XAB5IRn6WLNYDybZnJQesAJB7S Ga/SkJah6he26WIxGypVbH/BgutZD3rDnMIn9AuNN5PZtTn2kBTqoU9p4m5vJsNK8vEC g5PT7pjCPHyVHWbzilEBhoIMogqVUvekAYrv9bcVu+tccfLewC+kvYbv2rQ8BwUImFAV KmtAJrQxAVY0rLDA2uagA4FQCzEHDmyZiH3BoO/sP+YVGZjin+QixTHijNqo7X3oXKJ/ NHYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=yH+KDFMkZpDK8/kzdkQ3IueXEtpadmjmK9w1evB4sRA=; b=X0ClRMV3Qu+v83Bqc9PdySTY5zCyEx9hC96vEgkhrG+aXS+UA8Pi+dOcRmluVRbIGo YEHmXNAPqVy4WG48PtNifatIlKq2gAuLt6NeQoMHCjq7a20m3GtL6vU68Gy4PbfUCuI+ fo8Cvkrzb3XrhiCOgqJNHWwZq91zlb/c0NVFj8vJ8dp3IKPACpjbM67x9r9+y+X6I4MU cj4iPFSBPjzCFUHnuoFgVZFxifJgv0fqJq6KWmgjG6j0SZQonyihm7T35mLIzW/8BAxi QlrJZtSxhnlr1d3HVoH0NSDuKrVaFn98Zg62Scz4tq8htO3nkamBBbWBduKx4k0S7l9l VkRA== X-Gm-Message-State: ALoCoQnpEU+4xBVYnN0Tnbk1tlxgfxGBkLgo0YUIV7dUYzOPdGXZ+/TTNl6zgAMcBR6kNIROq82/L+Na6uWG5i7kWg3Kmmfp+w== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.50.56.82 with SMTP id y18mr1963857igp.40.1450204559234; Tue, 15 Dec 2015 10:35:59 -0800 (PST) Sender: antarus@scriptkitty.com Received: by 10.79.79.8 with HTTP; Tue, 15 Dec 2015 10:35:59 -0800 (PST) X-Originating-IP: [2620:0:1000:3001:bc99:df3a:63e2:7561] In-Reply-To: <20151215141936.GQ11489@vapier.lan> References: <22c8fc780e34e11cc460dcadda4202b4@omrb.pnpi.spb.ru> <22127.9478.374651.767331@a1i15.kph.uni-mainz.de> <20151215051334.GL11489@vapier.lan> <22127.45809.714763.942771@a1i15.kph.uni-mainz.de> <20151215141936.GQ11489@vapier.lan> Date: Tue, 15 Dec 2015 10:35:59 -0800 X-Google-Sender-Auth: hAdLZMbd2FdUTVbuC-UqmOsPvPo Message-ID: Subject: Re: [gentoo-dev] Use GLEP27! From: Alec Warner To: Gentoo Dev Content-Type: multipart/alternative; boundary=089e0158a9ba9b23d50526f40fb6 X-Archives-Salt: 04172720-2b10-4d22-97fe-b568ef2db51b X-Archives-Hash: 4597adb5d0627e5d2685af31c15d619f --089e0158a9ba9b23d50526f40fb6 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 15, 2015 at 6:19 AM, Mike Frysinger wrote: > On 15 Dec 2015 07:28, Ulrich Mueller wrote: > > >>>>> On Tue, 15 Dec 2015, Mike Frysinger wrote: > > > > > On 14 Dec 2015 21:22, Ulrich Mueller wrote: > > >> The spec seems incomplete. I cannot find a description of the user and > > >> group files' format. (But in fact, there is a standard format which > > >> suggests itself, namely that of the passwd(5) and group(5) files.) > > > > > i recall going with xml at the time, but i can't find reference to it. > > > > So the package manager would have to parse XML? We have tried to avoid > > that, so far. > > not entirely accurate considering we have metadata.xml > > > >> Also having whole directory trees seems wasteful and doesn't fit so > > >> well into the existing design of profiles. It might be simpler to put > > >> "user" (or "passwd") and "group" files directly in the profile. > > >> (If directories are really needed, we could use the scheme foreseen > > >> in [1] for package.* and use.* files.) > > > > > we implemented this GLEP in Chromium OS and have been using it for a > while: > > > > https://chromium.googlesource.com/chromiumos/overlays/eclass-overlay/+/master > > > > > having a directory of files is way more user friendly imo and allows > for > > > a format that is easier to read. /etc/passwd and /etc/group format are > > > not that easy to scan and aren't portable. > > > > As we most likely will introduce profile file directories in EAPI 7 > > (see bug 282296), I'd rather use the same scheme for the user and > > group files, but not something different. > > a flat text file akin to /etc/passwd is not readable. xml is readable. > u trollin' bro? > > a markdown like format would work -- easy to parse by machines & humans > and is a single stackable file. > user:ntp > uid:203 > gid:203 > user:man > uid:13 > gid:13 > (using : as delimiter since that's what *NIX uses in /etc/passwd) > > the main one would grow probably to about 2000+ lines (~400 users in the > tree and each entry takes ~4 lines assuming we enforce eliding of defaults) > which isn't that terrible. CrOS has a python script already for validating > the db consistency. > > > >> Also a mechanism how a subprofile could undefine a user or group > > >> defined in its parent seems to be missing. > > > > > what exactly do you mean by that ? you want to make it so attempts to > > > use the account yield an undefined error ? or you want to have it so > > > a child can revert back to an earlier definition ? > > > > The former. > > we already handle this in CrOS by explicitly including a flag in the file: > defunct:true > > thus the PM need not care about the status when locating files or otherwise > include any special handling. if the last file you hit is marked as > defunct, > then enew{user,group} will throw an error when they're called. > -mike > --089e0158a9ba9b23d50526f40fb6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 15, 2015 at 6:19 AM, Mike Frysinger <<= a href=3D"mailto:vapier@gentoo.org" target=3D"_blank">vapier@gentoo.org= > wrote:
On 15= Dec 2015 07:28, Ulrich Mueller wrote:
> >>>>> On Tue, 15 Dec 2015, Mike Frysinger wrote:
>
> > On 14 Dec 2015 21:22, Ulrich Mueller wrote:
> >> The spec seems incomplete. I cannot find a description of the= user and
> >> group files' format. (But in fact, there is a standard fo= rmat which
> >> suggests itself, namely that of the passwd(5) and group(5) fi= les.)
>
> > i recall going with xml at the time, but i can't find referen= ce to it.
>
> So the package manager would have to parse XML? We have tried to avoid=
> that, so far.

not entirely accurate considering we have metadata.xml

> >> Also having whole directory trees seems wasteful and doesn= 9;t fit so
> >> well into the existing design of profiles. It might be simple= r to put
> >> "user" (or "passwd") and "group"= ; files directly in the profile.
> >> (If directories are really needed, we could use the scheme fo= reseen
> >> in [1] for package.* and use.* files.)
>
> > we implemented this GLEP in Chromium OS and have been using it fo= r a while:
> > https://chrom= ium.googlesource.com/chromiumos/overlays/eclass-overlay/+/master
>
> > having a directory of files is way more user friendly imo and all= ows for
> > a format that is easier to read.=C2=A0 /etc/passwd and /etc/group= format are
> > not that easy to scan and aren't portable.
>
> As we most likely will introduce profile file directories in EAPI 7 > (see bug 282296), I'd rather use the same scheme for the user and<= br> > group files, but not something different.

a flat text file akin to /etc/passwd is not readable.=C2=A0 xml is r= eadable.

u trollin' bro?
= =C2=A0

a markdown like format would work -- easy to parse by machines & humans=
and is a single stackable file.
user:ntp
<whitespace>uid:203
<whitespace>gid:203
user:man
<whitespace>uid:13
<whitespace>gid:13
(using : as delimiter since that's what *NIX uses in /etc/passwd)

the main one would grow probably to about 2000+ lines (~400 users in the tree and each entry takes ~4 lines assuming we enforce eliding of defaults)=
which isn't that terrible.=C2=A0 CrOS has a python script already for v= alidating
the db consistency.

> >> Also a mechanism how a subprofile could undefine a user or gr= oup
> >> defined in its parent seems to be missing.
>
> > what exactly do you mean by that ?=C2=A0 you want to make it so a= ttempts to
> > use the account yield an undefined error ?=C2=A0 or you want to h= ave it so
> > a child can revert back to an earlier definition ?
>
> The former.

we already handle this in CrOS by explicitly including a flag in the= file:
defunct:true

thus the PM need not care about the status when locating files or otherwise=
include any special handling.=C2=A0 if the last file you hit is marked as d= efunct,
then enew{user,group} will throw an error when they're called.
-mike

--089e0158a9ba9b23d50526f40fb6--