On 11/28/2016 03:26 PM, M. J. Everitt wrote:
> On 28/11/16 19:39, William L. Thomson Jr. wrote:
>> For now who cares about other OS or distros. If Gentoo gets its house in
>> order
>> others may follow.
>>
> At the risk of a huge flame, remind me, who uses Gentoo again?!
>
Unless something's cha
On Wednesday, November 30, 2016 4:38:57 PM EST Michael Mol wrote:
>
> You're asserting that Red Hat and Debian do things differently because
> there's nobody to force them to do things the same way. It can't be because
> there's no reference for them to look at; for sure, the second into market
>
On Wednesday, November 30, 2016 03:25:21 PM William L. Thomson Jr. wrote:
> On Wednesday, November 30, 2016 3:08:30 PM EST Michael Mol wrote:
> > > IMHO it is something that should be a part of LSB. If not POSIX in
> > > general. One cannot really change the past or current state of things.
> > >
On Wednesday, November 30, 2016 3:08:30 PM EST Michael Mol wrote:
>
> > IMHO it is something that should be a part of LSB. If not POSIX in
> > general. One cannot really change the past or current state of things.
> > But can make
> the future better.
>
> > For now who cares about other OS or dis
On Wednesday, November 30, 2016 01:41:24 PM William L. Thomson Jr. wrote:
> On Wednesday, November 30, 2016 1:22:07 PM EST Michael Mol wrote:
> > If Gentoo wants to do it internally, that's one thing.
>
> This list is about Gentoo internal things
Here, let me bring up a bit of recent history from
On Wednesday, November 30, 2016 1:22:07 PM EST Michael Mol wrote:
>
>
> If Gentoo wants to do it internally, that's one thing.
This list is about Gentoo internal things
> But I would recommend
> against inviting other distributions to use Gentoo's list, which was
> something you seemed to be su
On Tuesday, November 29, 2016 04:49:24 PM William L. Thomson Jr. wrote:
> On Tuesday, November 29, 2016 10:40:20 AM EST Michael Mol wrote:
> > Highly detailed lists like that--used as a broad standard--are a bad idea.
> > They represent a single synchronization point that everyone must adhere
> > t
On 11/30/2016 10:23 AM, William L. Thomson Jr. wrote:
A couple more links, I should have provided initially as they better support
the argument.
First from Debian, I cannot find a list, but it is clearly mentioned.
"0-99:
Globally allocated by the Debian project, the same on every Debian system
A couple more links, I should have provided initially as they better support
the argument.
First from Debian, I cannot find a list, but it is clearly mentioned.
"0-99:
Globally allocated by the Debian project, the same on every Debian system"
https://www.debian.org/doc/debian-policy/ch-opersys.h
On Wednesday, November 30, 2016 8:54:42 AM EST Michał Górny wrote:
> On Tue, 29 Nov 2016 18:13:29 -0500
>
> "William L. Thomson Jr." wrote:
>>
> > I think you mean enewgroup and enewuser
>
> FYI, enew* functions handle UID/GID collisions gracefully, and just
> fallback to using next free UID/GID
On Tue, 29 Nov 2016 18:13:29 -0500
"William L. Thomson Jr." wrote:
> On Wednesday, November 30, 2016 12:49:44 AM EST Alan McKinnon wrote:
> >
> > Why would you end up with duplicated UIDs and GIDs? The only real ways
> > that can happen is
> > - ebuild "edits" passwd and group directly using ech
On Wednesday, November 30, 2016 12:49:44 AM EST Alan McKinnon wrote:
>
> Why would you end up with duplicated UIDs and GIDs? The only real ways
> that can happen is
> - ebuild "edits" passwd and group directly using echo/sed and the like.
> - ebuild runs useradd|groupadd specifying the uid/gid as
On 29/11/2016 23:49, William L. Thomson Jr. wrote:
> On Tuesday, November 29, 2016 10:40:20 AM EST Michael Mol wrote:
>>
>>
>> Highly detailed lists like that--used as a broad standard--are a bad idea.
>> They represent a single synchronization point that everyone must adhere to.
>
> That is a sta
On Tuesday, November 29, 2016 10:40:20 AM EST Michael Mol wrote:
>
>
> Highly detailed lists like that--used as a broad standard--are a bad idea.
> They represent a single synchronization point that everyone must adhere to.
That is a statement based on opinion. You say it is a bad idea. I say it
On Monday, November 28, 2016 02:39:48 PM William L. Thomson Jr. wrote:
> On Monday, November 28, 2016 10:42:54 AM EST Alec Warner wrote:
> > Generally speaking as a fellow who maintained thousands of systems (many
> > of
> > which ran various operating systems.)
> >
> > You cannot rely on all OS v
On 28/11/16 19:39, William L. Thomson Jr. wrote:
> For now who cares about other OS or distros. If Gentoo gets its house in
> order
> others may follow.
>
At the risk of a huge flame, remind me, who uses Gentoo again?!
signature.asc
Description: OpenPGP digital signature
On Monday, November 28, 2016 10:42:54 AM EST Alec Warner wrote:
>
> Generally speaking as a fellow who maintained thousands of systems (many of
> which ran various operating systems.)
>
> You cannot rely on all OS vendors to synchronize uid / gid. You cannot even
> rely on some single vendors to s
On Mon, Nov 28, 2016 at 8:21 AM, William L. Thomson Jr.
wrote:
> On Friday, November 25, 2016 11:39:15 PM EST Daniel Campbell wrote:
> >
> > I could see a use-case for someone wanting to install a given daemon or
> > server with a specific user and/or group. I'm not sure this is the right
> > app
On Friday, November 25, 2016 11:39:15 PM EST Daniel Campbell wrote:
>
> I could see a use-case for someone wanting to install a given daemon or
> server with a specific user and/or group. I'm not sure this is the right
> approach (nor do I know what is), but I think we have room to think
> about a
On 11/23/2016 01:08 AM, Michał Górny wrote:
> On Wed, 23 Nov 2016 09:44:33 +0100
> Manuel Rüger wrote:
>
>> I have not started to write it, but I am considering it and rather want
>> to gather feedback on my idea first.
>> I am aware that https://wiki.gentoo.org/wiki/GLEP:27 exists, but as of
>>
On 11/23/2016 12:44 AM, Manuel Rüger wrote:
> My only concerns right now are:
> Where to store those ${CATEGORY}-${PN}_user and ${CATEGORY}-${PN}_group?
> One solution could be to have another eclass named userkit-data.eclass,
> which is empty by default and needs to be forked to an overlay and the
On 11/23/2016 09:46 AM, Kent Fredric wrote:
> On Wed, 23 Nov 2016 09:44:33 +0100
> Manuel Rüger wrote:
>
>> What happens if the ebuild wants to create multiple users/group?
>> Currently, I want to ignore that case and focus on the 80% ebuilds that
>> can profit from such an eclass.
>
> You can s
On Wed, 23 Nov 2016 09:44:33 +0100
Manuel Rüger wrote:
> What happens if the ebuild wants to create multiple users/group?
> Currently, I want to ignore that case and focus on the 80% ebuilds that
> can profit from such an eclass.
You can solve that part quite easily really.
Just deem USERKIT_US
On Wed, 23 Nov 2016 10:19:42 +0100
Manuel Rüger wrote:
> On 23.11.2016 10:08, Michał Górny wrote:
> > On Wed, 23 Nov 2016 09:44:33 +0100
> > Manuel Rüger wrote:
> >
> >> I have not started to write it, but I am considering it and rather want
> >> to gather feedback on my idea first.
> >> I am
On 23.11.2016 10:08, Michał Górny wrote:
> On Wed, 23 Nov 2016 09:44:33 +0100
> Manuel Rüger wrote:
>
>> I have not started to write it, but I am considering it and rather want
>> to gather feedback on my idea first.
>> I am aware that https://wiki.gentoo.org/wiki/GLEP:27 exists, but as of
>> rig
On Wed, 23 Nov 2016 09:44:33 +0100
Manuel Rüger wrote:
> I have not started to write it, but I am considering it and rather want
> to gather feedback on my idea first.
> I am aware that https://wiki.gentoo.org/wiki/GLEP:27 exists, but as of
> right now I haven't seen anyone working on it. The goa
Hi everyone,
I have not started to write it, but I am considering it and rather want
to gather feedback on my idea first.
I am aware that https://wiki.gentoo.org/wiki/GLEP:27 exists, but as of
right now I haven't seen anyone working on it. The goal of this eclass
is to improve user/group handling
27 matches
Mail list logo
