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
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 cause growing frustration.
The problems I see today are:
1.
25 matches
Mail list logo
