On 12/10/19 11:05 AM, Joonas Niilola wrote:
>
> I was more thinking along sys admins being able to modify their acct-
> ebuilds with static numbers. If you're bind-mounting already, why not
> bind your portage (or local overlay) to children as well. 2 minute more
> work for those who need it, but
On Tue, 2019-12-10 at 18:13 +0200, Joonas Niilola wrote:
> On 12/10/19 3:34 PM, Michał Górny wrote:
> > > The problem: There is still no any official documentation about using
> > > acct-, and reviewing it was/is pretty much left on the shoulders of one
> > > man. It's easy to say on hindsight it
On 12/10/19 3:34 PM, Michał Górny wrote:
>> The problem: There is still no any official documentation about using
>> acct-, and reviewing it was/is pretty much left on the shoulders of one
>> man. It's easy to say on hindsight it was implemented too quickly.
> There is official documentation in
On 12/10/19 1:47 PM, Rich Freeman wrote:
>
> Having UIDs chosen completely at random seems fairly non-optimal.
> Suppose you're building containers/etc and then bind-mounting in
> persistent storage (/var/lib/mysql and so on). Wouldn't it be nice if
> the default were that mysql would get the
On Tue, Dec 10, 2019 at 9:50 AM Michael Orlitzky wrote:
>
> For esoteric packages with a dedicated user, though, you're probably
> right. The main benefit of the mailing list posts so far is that they
> let me track down pull requests and suggest that people ignore the
> example in the devmanual.
On Tue, 2019-12-10 at 09:50 -0500, Michael Orlitzky wrote:
> On 12/9/19 3:17 AM, Michał Górny wrote:
> > 2. Mailing list reviews don't serve their original purpose.
> >
> > The original purpose of mailing list reviews was to verify that
> > the developers use new packages correctly. For example,
On 12/9/19 3:17 AM, Michał Górny wrote:
>
> 2. Mailing list reviews don't serve their original purpose.
>
> The original purpose of mailing list reviews was to verify that
> the developers use new packages correctly. For example, Michael
> Orlitzky has found a lot of unnecessary home
On 12/9/19 3:10 PM, Thomas Deutschmann wrote:
> On 2019-12-09 19:48, Ulrich Mueller wrote:
>>> On Mon, 09 Dec 2019, Thomas Deutschmann wrote:
>>
>>> Like said, if an ID is already taken for any reason on user's system,
>>> that's not a problem. acct-* can handle that... there's nothing like a
On Tue, Dec 10, 2019 at 8:25 AM Thomas Deutschmann wrote:
>
> On 2019-12-10 13:44, Rich Freeman wrote:
> > I'm not talking about container-host mapping. I'm talking about
> > building the same container 100 times and having the container end up
> > with the same UIDs inside each time.
> >
> >
On Tue, 2019-12-10 at 07:44 +0200, Joonas Niilola wrote:
> Hey,
>
> On 12/9/19 10:17 AM, Michał Górny wrote:
> > Hello,
> >
> > I think the policies proposed in GLEP 81 [1] were overenthusiastic
> > and they don't stand collision with sad Gentoo developer reality.
> > Instead of improving the
On 2019-12-10 13:44, Rich Freeman wrote:
> I'm not talking about container-host mapping. I'm talking about
> building the same container 100 times and having the container end up
> with the same UIDs inside each time.
>
> Build order in portage isn't really deterministic, especially over
> long
On Tue, Dec 10, 2019 at 7:26 AM Thomas Deutschmann wrote:
>
> On 2019-12-10 12:47, Rich Freeman wrote:
> > Having UIDs chosen completely at random seems fairly non-optimal.
> > Suppose you're building containers/etc and then bind-mounting in
> > persistent storage (/var/lib/mysql and so on).
Hi,
On 2019-12-10 12:47, Rich Freeman wrote:
> Having UIDs chosen completely at random seems fairly non-optimal.
> Suppose you're building containers/etc and then bind-mounting in
> persistent storage (/var/lib/mysql and so on). Wouldn't it be nice if
> the default were that mysql would get the
On Tue, Dec 10, 2019 at 12:44 AM Joonas Niilola wrote:
>
> Honestly I'd say just put -1 on all acct- packages then let sys admins
> modify them locally to whatever they need. I feel like this whole GLEP
> just serves the minority while making many other contributors uneasy.
>
I think we're
Hey,
On 12/9/19 10:17 AM, Michał Górny wrote:
> Hello,
>
> I think the policies proposed in GLEP 81 [1] were overenthusiastic
> and they don't stand collision with sad Gentoo developer reality.
> Instead of improving the quality of resulting packages, they rather
> hamper their adoption and
On Mon, 2019-12-09 at 13:48 -0800, Alec Warner wrote:
> On Mon, Dec 9, 2019 at 12:17 AM Michał Górny wrote:
>
> > Hello,
> >
> > I think the policies proposed in GLEP 81 [1] were overenthusiastic
> > and they don't stand collision with sad Gentoo developer reality.
> > Instead of improving the
On Mon, Dec 9, 2019 at 12:17 AM Michał Górny wrote:
> Hello,
>
> I think the policies proposed in GLEP 81 [1] were overenthusiastic
> and they don't stand collision with sad Gentoo developer reality.
> Instead of improving the quality of resulting packages, they rather
> hamper their adoption
On 2019-12-09 19:48, Ulrich Mueller wrote:
>> On Mon, 09 Dec 2019, Thomas Deutschmann wrote:
>
>> Like said, if an ID is already taken for any reason on user's system,
>> that's not a problem. acct-* can handle that... there's nothing like a
>> collision.
>
> You can call it "collision" or
> On Mon, 09 Dec 2019, Thomas Deutschmann wrote:
> Like said, if an ID is already taken for any reason on user's system,
> that's not a problem. acct-* can handle that... there's nothing like a
> collision.
You can call it "collision" or something else, the fact is that in this
scenario, the
On 2019-12-09 18:47, Ulrich Mueller wrote:
> One problem with that is that at some time user.eclass dynamically
> allocated IDs starting at 101 upwards, and later this was changed to 999
> downwards (at different times for UIDs and GIDs). So for existing
> systems you can expect some range above
> On Mon, 09 Dec 2019, Thomas Deutschmann wrote:
> Make complete SYS_UID_MIN - SYS_UID_MAX range available for GLEP 81.
> The only argument/reason I am aware of, "but 501-999 could be used by
> system" (Dynamic allocation by user.eclass), isn't strong enough from my
> POV because system
Hi,
I fully agree with #3. But I would go one step further:
Make complete SYS_UID_MIN - SYS_UID_MAX range available for GLEP 81.
The only argument/reason I am aware of, "but 501-999 could be used by
system" (Dynamic allocation by user.eclass), isn't strong enough from my
POV because system
> On Mon, 09 Dec 2019, Ulrich Mueller wrote:
>> a. split the UID/GID range into 'high' (app) and 'low' (system)
>> assignments, 'high' being >=100 and 'low' <100 (matching Apache suEXEC
>> defaults),
> Good, but can we make these ranges more explicit please, like 100..499
> for "high" and
> On Mon, 09 Dec 2019, Michał Górny wrote:
> My proposal would be to:
> a. split the UID/GID range into 'high' (app) and 'low' (system)
> assignments, 'high' being >=100 and 'low' <100 (matching Apache suEXEC
> defaults),
Good, but can we make these ranges more explicit please, like
24 matches
Mail list logo
