On Fri, Jan 8, 2021 at 1:31 PM Michał Górny wrote:
> Again, I don't understand why you continue escalating this. I have
> already indicated that I'm fine with adding an option to disable this,
> given that 1) the current behavior remains the default, and 2) people
> are given big fat warning that
On Fri, 2021-01-08 at 19:23 +0100, Thomas Deutschmann wrote:
> On 2021-01-08 19:14, Michał Górny wrote:
> > The one floppym suggested, i.e. the same as sent patch but with
> > the default staying on the current behavior.
>
> Do I understand correctly? You are willing to accept my patch but with
>
On Fri, 2021-01-08 at 19:10 +0100, Thomas Deutschmann wrote:
> On 2021-01-08 18:06, Mike Gilbert wrote:
> > I disagree with your premise: I argue that the eclass is not "broken",
> > and the code works as designed. You just don't like aspects of its
> > design.
>
> Several people, not just me... *
On 2021-01-08 19:14, Michał Górny wrote:
The one floppym suggested, i.e. the same as sent patch but with
the default staying on the current behavior.
Do I understand correctly? You are willing to accept my patch but with
> ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED
defaulting to a non-zero
On Fri, 2021-01-08 at 19:11 +0100, Fabian Groffen wrote:
> On 04-01-2021 17:14:47 +0100, Michał Górny wrote:
> > Yes, I don't mind an option, as long as it spews a big fat ewarn that
> > the user loses the right to support. However, that's still not
> > the right solution to the immediate problem,
On 04-01-2021 17:14:47 +0100, Michał Górny wrote:
> Yes, I don't mind an option, as long as it spews a big fat ewarn that
> the user loses the right to support. However, that's still not
> the right solution to the immediate problem, and I'm currently working
> on a better patch, so I'd prefer if
On 2021-01-08 18:06, Mike Gilbert wrote:
I disagree with your premise: I argue that the eclass is not "broken",
and the code works as designed. You just don't like aspects of its
design.
Several people, not just me... *users*, other devs like robbat2 and
antarus, all with experience in maintai
On Fri, 2021-01-08 at 17:29 +0100, Thomas Deutschmann wrote:
> On 2021-01-08 17:03, Mike Gilbert wrote:
> > I strongly object to you pushing this patch as-is. There have been
> > plenty of non-technical objections, including from the eclass
> > maintainer.
>
> The eclass maintainer has disqualifie
On Fri, Jan 8, 2021 at 11:29 AM Thomas Deutschmann wrote:
> This is a technical mailing list. Currently, acct-* stuff is breaking
> stuff. Nobody has challenged this yet.
>
> Now I proposed a way how to unbreak stuff.
>
> Please tell me why we should keep broken stuff for non-technical reason
> an
On Fri, Jan 8, 2021 at 11:29 AM Thomas Deutschmann wrote:
>
> On 2021-01-08 17:03, Mike Gilbert wrote:
> > I strongly object to you pushing this patch as-is. There have been
> > plenty of non-technical objections, including from the eclass
> > maintainer.
>
> The eclass maintainer has disqualified
On 2021-01-08 17:03, Mike Gilbert wrote:
I strongly object to you pushing this patch as-is. There have been
plenty of non-technical objections, including from the eclass
maintainer.
The eclass maintainer has disqualified himself going into a technical
debate with saying
So, over my dead com
On Fri, Jan 8, 2021 at 10:48 AM Thomas Deutschmann wrote:
>
> Hi,
>
> since nobody posted any technical objections, I am going to push the
> proposed patch on Saturday to address the current issue and allow any
> professional Gentoo user relying on usermod/configuration management
> tool to move o
Hi,
since nobody posted any technical objections, I am going to push the
proposed patch on Saturday to address the current issue and allow any
professional Gentoo user relying on usermod/configuration management
tool to move on.
If someone will spend time on further improvements like impleme
On Mon, Jan 4, 2021 at 11:50 AM Thomas Deutschmann wrote:
>
> On 2021-01-04 17:38, Michał Górny wrote:
> > You've actually added 'portage' to group 'thomas'.
>
> Yes, I know that.
>
> Well, I understand why this might be confusing for you. Like I was using
> portage as example for the described ex
On Mon, 2021-01-04 at 17:50 +0100, Thomas Deutschmann wrote:
> On 2021-01-04 17:38, Michał Górny wrote:
> > You've actually added 'portage' to group 'thomas'.
>
> Yes, I know that.
>
> Well, I understand why this might be confusing for you. Like I was using
> portage as example for the described
On Mon, Jan 4, 2021 at 11:34 AM Thomas Deutschmann wrote:
>
> On 2021-01-04 17:30, Thomas Deutschmann wrote:
> > On 2021-01-04 17:28, Michał Górny wrote:
> >> It must be a bug in your version of the eclass. I've just reemerged
> >> acct-group/wheel and to*my great surprise* I'm still there. How
On 2021-01-04 17:38, Michał Górny wrote:
You've actually added 'portage' to group 'thomas'.
Yes, I know that.
Well, I understand why this might be confusing for you. Like I was using
portage as example for the described example when you give another
service access to a socket like shown in m
On Mon, 2021-01-04 at 17:34 +0100, Thomas Deutschmann wrote:
> On 2021-01-04 17:30, Thomas Deutschmann wrote:
> > On 2021-01-04 17:28, Michał Górny wrote:
> > > It must be a bug in your version of the eclass. I've just reemerged
> > > acct-group/wheel and to*my great surprise* I'm still there. H
On 2021-01-04 17:30, Thomas Deutschmann wrote:
On 2021-01-04 17:28, Michał Górny wrote:
It must be a bug in your version of the eclass. I've just reemerged
acct-group/wheel and to*my great surprise* I'm still there. How
unexpected!
That's why I wrote
> (luckily groups like wheel don't ha
On 2021-01-04 17:28, Michał Górny wrote:
It must be a bug in your version of the eclass. I've just reemerged
acct-group/wheel and to*my great surprise* I'm still there. How
unexpected!
That's why I wrote
> (luckily groups like wheel don't have users...)
I meant that there is no acct-user/
On Mon, 2021-01-04 at 17:18 +0100, Thomas Deutschmann wrote:
> On 2021-01-04 16:55, David Seifert wrote:
> > This is what we agree on. We need an escape hatch, and it needs to be
> > off by default. Any sysadmin overriding it gets to keep the pieces, but
> > they need to have that option.
>
> See
On 2021-01-04 17:14, Michał Górny wrote:
as long as it spews a big fat ewarn that the user loses the right to
support.
Could you please elaborate this a little bit more? I cannot agree with
the way I understand this at the moment but I might miss your point.
--
Regards,
Thomas Deutschmann /
On 2021-01-04 16:55, David Seifert wrote:
This is what we agree on. We need an escape hatch, and it needs to be
off by default. Any sysadmin overriding it gets to keep the pieces, but
they need to have that option.
See Mike's example again.
In last chapter of Gentoo's handbook (Finalization) w
On Mon, 2021-01-04 at 11:10 -0500, Mike Gilbert wrote:
> On Mon, Jan 4, 2021 at 4:23 AM Michał Górny wrote:
> >
> > On Mon, 2021-01-04 at 02:35 +0100, Thomas Deutschmann wrote:
> > > Modifying an existing user is a bad default and makes Gentoo
> > > special because it is common for system adminis
On Mon, Jan 4, 2021 at 4:23 AM Michał Górny wrote:
>
> On Mon, 2021-01-04 at 02:35 +0100, Thomas Deutschmann wrote:
> > Modifying an existing user is a bad default and makes Gentoo
> > special because it is common for system administrators to make
> > modifications to user (i.e. putting an user in
On Mon, 2021-01-04 at 10:24 -0500, Michael Orlitzky wrote:
> I understand that creating an overlay with acct-user overrides will
> not
> be for everyone, so I have no problem with adding an escape hatch. I
> do
> think it should be off by default though, and that missing future
> ::gentoo change
On 1/4/21 9:46 AM, Thomas Deutschmann wrote:
So the main problem I see with doing this is that it becomes
impossible to reliably make changes to a user in later ebuild
revisions.
He is obviously looking for a way to allow maintainers to change users
afterwards. But if we tell people, "If you
Hi,
On 2021-01-04 04:18, Michael Orlitzky wrote:
It would be nice if this was well-supported by the official way of
modifying system users/groups; that is, by using an overlay with
modified user/group ebuilds.
No, this doesn't work:
1) It's conflicting with the goals other have. See Mike's f
On 2021-01-04 10:23, Michał Górny wrote:
Not modifying an existing user is a horrible default that has already
bricked one system (by removing /dev/null). So, over my dead commit
access.
Have you seen how many user were hit caused by the recent rebuilt on
2020-12-28 and are already complainin
On Mon, 2021-01-04 at 02:35 +0100, Thomas Deutschmann wrote:
> Modifying an existing user is a bad default and makes Gentoo
> special because it is common for system administrators to make
> modifications to user (i.e. putting an user into another service's
> group to allow that user to access serv
Whissi's patch in itself is a good step forward, but I don't feel it
goes far enough, nor promotes better defaults for the unmodified cases.
On Mon, Jan 04, 2021 at 02:35:58AM +0100, Thomas Deutschmann wrote:
> Modifying an existing user is a bad default and makes Gentoo
> special because it is
On 1/3/21 8:35 PM, Thomas Deutschmann wrote:
Modifying an existing user is a bad default and makes Gentoo
special because it is common for system administrators to make
modifications to user (i.e. putting an user into another service's
group to allow that user to access service in question) and i
On Sun, Jan 3, 2021 at 6:42 PM Mike Gilbert wrote:
>
> On Sun, Jan 3, 2021 at 8:35 PM Thomas Deutschmann wrote:
> >
> > Modifying an existing user is a bad default and makes Gentoo
> > special because it is common for system administrators to make
> > modifications to user (i.e. putting an user i
On Sun, Jan 3, 2021 at 8:35 PM Thomas Deutschmann wrote:
>
> Modifying an existing user is a bad default and makes Gentoo
> special because it is common for system administrators to make
> modifications to user (i.e. putting an user into another service's
> group to allow that user to access servi
Modifying an existing user is a bad default and makes Gentoo
special because it is common for system administrators to make
modifications to user (i.e. putting an user into another service's
group to allow that user to access service in question) and it
would be unexpected to see these changes reve
35 matches
Mail list logo
