[gentoo-dev] enewuser/enewgroup getting their own eclass

[gentoo-dev] enewuser/enewgroup getting their own eclass

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

OK.  I've been looking at some of these issues we've been having, and
I've been thinking of moving enewuser, egetent, and enewgroup to their
own eclass.  This will resolve some issues with things in system, or
otherwise early on, requiring shadow on Linux to get useradd.  Two
examples of this are bug #113298 and bug #94745.  By putting them in
their own eclass, we can keep from adding shadow to DEPEND in eutils,
while still putting the dependency in the eclass that uses it.

I'd be willing to make all the changes to the tree to facilitate this,
and unless someone has a really good reason not to do so, I think I'll
probably do it after the Thanksgiving holiday.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] enewuser/enewgroup getting their own eclass

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

On Wednesday 23 November 2005 19:15, Chris Gianelloni wrote:
> I'd be willing to make all the changes to the tree to facilitate this,
> and unless someone has a really good reason not to do so, I think I'll
> probably do it after the Thanksgiving holiday.
Well if you can give us an ISO date it would be simpler ;) Mainly because I 
have nfc when "Thanksgiving holiday" is...

Anyway, please remember to put shadow's dependency under userland_GNU? ( ) 
conditional or it will break Gentoo/ALT systems.
And I think we could move there egethome at that point, if there are no 
problems with moving functions around eclasses.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] enewuser/enewgroup getting their own eclass

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]

On Wed, Nov 23, 2005 at 01:15:52PM -0500, Chris Gianelloni wrote:
> OK.  I've been looking at some of these issues we've been having, and
> I've been thinking of moving enewuser, egetent, and enewgroup to their
> own eclass.  This will resolve some issues with things in system, or
> otherwise early on, requiring shadow on Linux to get useradd.  Two
> examples of this are bug #113298 and bug #94745. By putting them in
> their own eclass, we can keep from adding shadow to DEPEND in eutils,
> while still putting the dependency in the eclass that uses it.

You do this, and you'll break binpkgs that rely on it existing in 
eutils.  Yes it's annoying, but you _have_ to lead the functionality 
in eutils, duplicating it into whatever class you shove it into.

That's the other side of the "can't remove eclasses" rule- can't yank 
functionality that is going to break installed ebuilds and binpkgs.

> I'd be willing to make all the changes to the tree to facilitate this,
> and unless someone has a really good reason not to do so, I think I'll
> probably do it after the Thanksgiving holiday.

I'd delay this a bit personally, since it's a widespread change, and 
because people are probably going to be offline due to holiday cruft.

Yah... you probably have the time to do it during the holiday stuff, 
but again, affecting a sizable collection of packages and requires 
ebuild devs to change the eclasses they're using.

Plus the binpkg issue from above. ;)
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] enewuser/enewgroup getting their own eclass

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

On Wed, 2005-11-23 at 19:30 +0100, Diego 'Flameeyes' Pettenò wrote:
> On Wednesday 23 November 2005 19:15, Chris Gianelloni wrote:
> > I'd be willing to make all the changes to the tree to facilitate this,
> > and unless someone has a really good reason not to do so, I think I'll
> > probably do it after the Thanksgiving holiday.
> Well if you can give us an ISO date it would be simpler ;) Mainly because I 
> have nfc when "Thanksgiving holiday" is...

ISO date == anytime after tomorrow

> Anyway, please remember to put shadow's dependency under userland_GNU? ( ) 
> conditional or it will break Gentoo/ALT systems.
> And I think we could move there egethome at that point, if there are no 
> problems with moving functions around eclasses.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] enewuser/enewgroup getting their own eclass

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2580 bytes --]

On Wed, 2005-11-23 at 12:52 -0600, Brian Harring wrote:
> On Wed, Nov 23, 2005 at 01:15:52PM -0500, Chris Gianelloni wrote:
> > OK.  I've been looking at some of these issues we've been having, and
> > I've been thinking of moving enewuser, egetent, and enewgroup to their
> > own eclass.  This will resolve some issues with things in system, or
> > otherwise early on, requiring shadow on Linux to get useradd.  Two
> > examples of this are bug #113298 and bug #94745. By putting them in
> > their own eclass, we can keep from adding shadow to DEPEND in eutils,
> > while still putting the dependency in the eclass that uses it.
> 
> You do this, and you'll break binpkgs that rely on it existing in 
> eutils.  Yes it's annoying, but you _have_ to lead the functionality 
> in eutils, duplicating it into whatever class you shove it into.

I had thought that this was resolved already in portage.

> That's the other side of the "can't remove eclasses" rule- can't yank 
> functionality that is going to break installed ebuilds and binpkgs.

Fine.  I can simply make a new eclass and change the affected ebuilds.
I really don't have a problem with this.  The main reason for it is that
whatever eclass that enewuser is in really needs to DEPEND on shadow on
Linux.  Which brings up another point.  I see that a good number of
packages are calling enewuser in pkg_preinst.

These packages do not need shadow (though the system might, but that's
outside my scope) once they are installed, only to install.  However, it
is not needed to build.  What *DEPEND is correct?

> > I'd be willing to make all the changes to the tree to facilitate this,
> > and unless someone has a really good reason not to do so, I think I'll
> > probably do it after the Thanksgiving holiday.
> 
> I'd delay this a bit personally, since it's a widespread change, and 
> because people are probably going to be offline due to holiday cruft.

I was planning on taking care of it myself.  I was going to remove the
functions from eutils.eclass as my last step, but now I would simply
skip that step.  I would probably do something like add a warning to the
functions under eutils.eclass, too.

> Yah... you probably have the time to do it during the holiday stuff, 
> but again, affecting a sizable collection of packages and requires 
> ebuild devs to change the eclasses they're using.
> 
> Plus the binpkg issue from above. ;)
> ~harring
-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] enewuser/enewgroup getting their own eclass

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Gianelloni wrote:
| These packages do not need shadow (though the system might, but that's
| outside my scope) once they are installed, only to install.  However, it
| is not needed to build.  What *DEPEND is correct?

It fits into RDEPEND (oddly enough), since binpkgs will need it as well
and they don't get DEPEND stuff.

Thanks,
Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDhMWnXVaO67S1rtsRAv4RAJ45Wsjoz4wBzpjI+Tw3S7LAdw7NXACguR4H
9kHmi0rLZHbd69kQZlZNTW4=
=GfzO
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] enewuser/enewgroup getting their own eclass

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

On Wed, 2005-11-23 at 11:40 -0800, Donnie Berkholz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Chris Gianelloni wrote:
> | These packages do not need shadow (though the system might, but that's
> | outside my scope) once they are installed, only to install.  However, it
> | is not needed to build.  What *DEPEND is correct?
> 
> It fits into RDEPEND (oddly enough), since binpkgs will need it as well
> and they don't get DEPEND stuff.

That is what I thought.  I was just wondering if there were some other
*DEPEND that I wasn't aware of that fit the bill of "needed for
installing from a package but not needed afterwards".  It doesn't
*really* matter since shadow is in "system" on any machine this would
affect anyway, but you get my thinking.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: enewuser/enewgroup getting their own eclass

[Duncan]

Diego 'Flameeyes' Pettenò posted
<200511231930.38340@enterprise.flameeyes.is-a-geek.org>, excerpted below, 
on Wed, 23 Nov 2005 19:30:21 +0100:

> On Wednesday 23 November 2005 19:15, Chris Gianelloni wrote:
>> I'd be willing to make all the changes to the tree to facilitate this,
>> and unless someone has a really good reason not to do so, I think I'll
>> probably do it after the Thanksgiving holiday.
> Well if you can give us an ISO date it would be simpler ;) Mainly because
> I have nfc when "Thanksgiving holiday" is...

Fourth Thursday in November... so tomorrow...

However, traditionally, it's a long weekend, with office and government
workers having Friday off as well, and Friday then becoming the biggest
shopping day of the year (many stores open at 6 AM and have 1 hour, two
hour, 'till noon, and/or rotating hourly specials) as the first day of
the "official" Christmas shopping season, and often the only
non-weekend day many office workers get.

Thus, "after the Thanksgiving holiday" could mean either on Friday, or
after the weekend, Monday/Tueday-ish, so it's still a bit ambiguous.  In
any case, it's relatively soon, altho with the message just posted, Friday
would give half the time to respond compared to early next week.

>From an outside perspective, I'm sure it's amazing and crass that USians
see nothing unusual about the national holiday of thanks being
directly followed by the biggest day of commercial greed in the entire
year, as the opening day of the biggest season of commercial greed,
obsensibly as preparation for the day of celebration of the birth of Jesus
Christ, the man seen as the Son of God, and quoted as saying it's easier
for a camel to pass thru the eye of a needle than for a rich man to get
into paradise!  Interesting commentary on our culture!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: enewuser/enewgroup getting their own eclass

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 378 bytes --]

On Wed, Nov 23, 2005 at 01:06:18PM -0700, Duncan wrote:
> Fourth Thursday in November... so tomorrow...
Except in Canada, where it falls on the second Monday in October.
So Chris might to well to have a time-machine and make the change last
month.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]

Re: [gentoo-dev] Re: enewuser/enewgroup getting their own eclass

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

On Wed, 2005-11-23 at 13:06 -0700, Duncan wrote:
> From an outside perspective, I'm sure it's amazing and crass that USians
> see nothing unusual about the national holiday of thanks being
> directly followed by the biggest day of commercial greed in the entire
> year, as the opening day of the biggest season of commercial greed,
> obsensibly as preparation for the day of celebration of the birth of Jesus
> Christ, the man seen as the Son of God, and quoted as saying it's easier
> for a camel to pass thru the eye of a needle than for a rich man to get
> into paradise!  Interesting commentary on our culture!

What the hell does this have to do with Gentoo development?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] enewuser/enewgroup getting their own eclass

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Gianelloni wrote:
| That is what I thought.  I was just wondering if there were some other
| *DEPEND that I wasn't aware of that fit the bill of "needed for
| installing from a package but not needed afterwards".  It doesn't
| *really* matter since shadow is in "system" on any machine this would
| affect anyway, but you get my thinking.

/me begins clamoring for IDEPEND (install-time deps).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDhNNUXVaO67S1rtsRAodMAJ0ZxD7gWiRU7r1SggpH/Bgd7NZ4mACg2N8Y
onOzQzXwd/6hrO7+acpLonQ=
=qGhH
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] enewuser/enewgroup getting their own eclass

[Donnie Berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Henrik Brix Andersen wrote:
| I've read the initial post a couple of times now, and I still don't
| get it.
|
| Could somebody please clarify how this differs from DEPEND?

Because DEPEND is only needed for the actual build (src_* functions).
With binary packages, all the pkg_* functions are run but DEPEND
packages are not required to be installed. So anything external run in a
pkg_* function must be in RDEPEND because it cannot be just in DEPEND,
and those are the only two options.

Does that help?

Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDhNkEXVaO67S1rtsRAgpEAJ9R9k6mFV4qJXCs86OR6ENDNJgq+gCeKesw
hEdAKjFvheFx0rJFkRLFYso=
=+Df3
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: enewuser/enewgroup getting their own eclass

[Duncan]

Chris Gianelloni posted
<1132777755.27288.161.camel@cgianelloni.nuvox.net>, excerpted below,  on
Wed, 23 Nov 2005 15:29:15 -0500:

> On Wed, 2005-11-23 at 13:06 -0700, Duncan wrote:
>> From an outside perspective, I'm sure it's amazing and crass that USians
>> see nothing unusual about the national holiday of thanks being directly
>> followed by the biggest day of commercial greed in the entire year, as
>> the opening day of the biggest season of commercial greed, obsensibly as
>> preparation for the day of celebration of the birth of Jesus Christ, the
>> man seen as the Son of God, and quoted as saying it's easier for a camel
>> to pass thru the eye of a needle than for a rich man to get into
>> paradise!  Interesting commentary on our culture!
> 
> What the hell does this have to do with Gentoo development?

About the same as the original reference to "after the Thanksgiving
holiday" which prompted the question to which it is a reply, which was in
the context you snipped.  As such, certainly as much or more than
oblique references to harems and goats and people's butts (well, unless
there's something about Gentoo development I don't know about, yet <g>),
all topics that have come up in passing on the list, just as this
did, without this question being asked of those posters.

It may be possible to automate code creation, but it's not possible to
automate a community, and humans in such a community /don't/ tend to stay
strictly on topic. That's just the way humans are, and have been for far
longer than either you or I have been around.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: enewuser/enewgroup getting their own eclass

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

On Wed, 23 Nov 2005 14:14:31 -0700 Duncan <1i5t5.duncan@cox.net> wrote:
| It may be possible to automate code creation, but it's not possible to
| automate a community

This list is not about making a 'community'. It's about getting
development done. If you want to go and make lots of noise about
communities, go and do it on the forums or somewhere else where you
won't be wasting our time.

-- 
Ciaran McCreesh : Gentoo Developer (Look! Shiny things!)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: enewuser/enewgroup getting their own eclass

[Ned Ludd]

On Wed, 2005-11-23 at 14:14 -0700, Duncan wrote:
> Chris Gianelloni posted
> <1132777755.27288.161.camel@cgianelloni.nuvox.net>, excerpted below,  on
> Wed, 23 Nov 2005 15:29:15 -0500:
> 
> > On Wed, 2005-11-23 at 13:06 -0700, Duncan wrote:
> >> From an outside perspective, I'm sure it's amazing and crass that USians
> >> see nothing unusual about the national holiday of thanks being directly
> >> followed by the biggest day of commercial greed in the entire year, as
> >> the opening day of the biggest season of commercial greed, obsensibly as
> >> preparation for the day of celebration of the birth of Jesus Christ, the
> >> man seen as the Son of God, and quoted as saying it's easier for a camel
> >> to pass thru the eye of a needle than for a rich man to get into
> >> paradise!  Interesting commentary on our culture!
> > 
> > What the hell does this have to do with Gentoo development?
> 
> About the same as the original reference to "after the Thanksgiving
> holiday" which prompted the question to which it is a reply, which was in
> the context you snipped.  As such, certainly as much or more than
> oblique references to harems and goats and people's butts (well, unless
> there's something about Gentoo development I don't know about, yet <g>),
> all topics that have come up in passing on the list, just as this
> did, without this question being asked of those posters.
> 
> It may be possible to automate code creation, but it's not possible to
> automate a community, and humans in such a community /don't/ tend to stay
> strictly on topic. That's just the way humans are, and have been for far
> longer than either you or I have been around.

Your either high or in need of a blog.


-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: enewuser/enewgroup getting their own eclass

[Jakub Moc]

[-- Attachment #1: Type: text/plain, Size: 783 bytes --]


23.11.2005, 22:14:31, Duncan wrote:

[irrelevant twaddle omitted]

> It may be possible to automate code creation, but it's not possible to
> automate a community, and humans in such a community /don't/ tend to stay
> strictly on topic. That's just the way humans are, and have been for far
> longer than either you or I have been around.

I can't speak for others, but personally I'm not interested in receiving such
crap in my mailbox. There's enough traffic here as it is. Please, keep on topic
or go chat elsewhere.


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 183 bytes --]

Re: [gentoo-dev] enewuser/enewgroup getting their own eclass

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 378 bytes --]

On Wed, Nov 23, 2005 at 12:38:44PM -0800, Donnie Berkholz wrote:
> /me begins clamoring for IDEPEND (install-time deps).

I've read the initial post a couple of times now, and I still don't
get it.

Could somebody please clarify how this differs from DEPEND?

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --]

Re: [gentoo-dev] enewuser/enewgroup getting their own eclass

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

On Wed, Nov 23, 2005 at 01:03:00PM -0800, Donnie Berkholz wrote:
> Because DEPEND is only needed for the actual build (src_* functions).
> With binary packages, all the pkg_* functions are run but DEPEND
> packages are not required to be installed. So anything external run in a
> pkg_* function must be in RDEPEND because it cannot be just in DEPEND,
> and those are the only two options.
> 
> Does that help?

Yes, thank you - now I understand the issue :)

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --]

Re: [gentoo-dev] enewuser/enewgroup getting their own eclass

[Mike Frysinger]

On Wed, Nov 23, 2005 at 01:15:52PM -0500, Chris Gianelloni wrote:
> OK.  I've been looking at some of these issues we've been having, and
> I've been thinking of moving enewuser, egetent, and enewgroup to their
> own eclass.  This will resolve some issues with things in system, or
> otherwise early on, requiring shadow on Linux to get useradd.  Two
> examples of this are bug #113298 and bug #94745.  By putting them in
> their own eclass, we can keep from adding shadow to DEPEND in eutils,
> while still putting the dependency in the eclass that uses it.

i think i suggested this somewhere before, but why dont we just add
shadow to packages.build ... then it'll be in stage[123] and the DEPEND
will be a moot point
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] enewuser/enewgroup getting their own eclass

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

On Thu, 2005-11-24 at 03:44 +0000, Mike Frysinger wrote:
> On Wed, Nov 23, 2005 at 01:15:52PM -0500, Chris Gianelloni wrote:
> > OK.  I've been looking at some of these issues we've been having, and
> > I've been thinking of moving enewuser, egetent, and enewgroup to their
> > own eclass.  This will resolve some issues with things in system, or
> > otherwise early on, requiring shadow on Linux to get useradd.  Two
> > examples of this are bug #113298 and bug #94745.  By putting them in
> > their own eclass, we can keep from adding shadow to DEPEND in eutils,
> > while still putting the dependency in the eclass that uses it.
> 
> i think i suggested this somewhere before, but why dont we just add
> shadow to packages.build ... then it'll be in stage[123] and the DEPEND
> will be a moot point

That doesn't solve the issue.  The issue is that cronbase *needs* shadow
in its dependency tree to force portage to install shadow before
cronbase when doing an emerge -e system.  It has nothing to do with the
stages.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] enewuser/enewgroup getting their own eclass

[Mike Frysinger]

On Thu, Nov 24, 2005 at 08:54:41AM -0500, Chris Gianelloni wrote:
> On Thu, 2005-11-24 at 03:44 +0000, Mike Frysinger wrote:
> > On Wed, Nov 23, 2005 at 01:15:52PM -0500, Chris Gianelloni wrote:
> > > OK.  I've been looking at some of these issues we've been having, and
> > > I've been thinking of moving enewuser, egetent, and enewgroup to their
> > > own eclass.  This will resolve some issues with things in system, or
> > > otherwise early on, requiring shadow on Linux to get useradd.  Two
> > > examples of this are bug #113298 and bug #94745.  By putting them in
> > > their own eclass, we can keep from adding shadow to DEPEND in eutils,
> > > while still putting the dependency in the eclass that uses it.
> > 
> > i think i suggested this somewhere before, but why dont we just add
> > shadow to packages.build ... then it'll be in stage[123] and the DEPEND
> > will be a moot point
> 
> That doesn't solve the issue.

of course it does ... putting a package in packages.build means it will
be in all stages which means no package (like cronbase) will ever fail
again because the useradd binaries will always exist
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] enewuser/enewgroup getting their own eclass

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1785 bytes --]

On Thu, 2005-11-24 at 19:34 +0000, Mike Frysinger wrote:
> On Thu, Nov 24, 2005 at 08:54:41AM -0500, Chris Gianelloni wrote:
> > On Thu, 2005-11-24 at 03:44 +0000, Mike Frysinger wrote:
> > > On Wed, Nov 23, 2005 at 01:15:52PM -0500, Chris Gianelloni wrote:
> > > > OK.  I've been looking at some of these issues we've been having, and
> > > > I've been thinking of moving enewuser, egetent, and enewgroup to their
> > > > own eclass.  This will resolve some issues with things in system, or
> > > > otherwise early on, requiring shadow on Linux to get useradd.  Two
> > > > examples of this are bug #113298 and bug #94745.  By putting them in
> > > > their own eclass, we can keep from adding shadow to DEPEND in eutils,
> > > > while still putting the dependency in the eclass that uses it.
> > > 
> > > i think i suggested this somewhere before, but why dont we just add
> > > shadow to packages.build ... then it'll be in stage[123] and the DEPEND
> > > will be a moot point
> > 
> > That doesn't solve the issue.
> 
> of course it does ... putting a package in packages.build means it will
> be in all stages which means no package (like cronbase) will ever fail
> again because the useradd binaries will always exist

I'm looking to minimize what is in a stage1 tarball, not increase it.  I
would much prefer that we instead had a proper dependency tree, than
hacking around it.  Applications that need to add users on Linux
*should* DEPEND on shadow.  They should not rely on it being already
present.  Plus, your solution does not work retroactively to repair
issues with the 2005.0, 2005.1, or 2005.1-r1 stages, while mine does.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] enewuser/enewgroup getting their own eclass

[Mike Frysinger]

On Fri, Nov 25, 2005 at 09:24:44AM -0500, Chris Gianelloni wrote:
> On Thu, 2005-11-24 at 19:34 +0000, Mike Frysinger wrote:
> > On Thu, Nov 24, 2005 at 08:54:41AM -0500, Chris Gianelloni wrote:
> > > On Thu, 2005-11-24 at 03:44 +0000, Mike Frysinger wrote:
> > > > On Wed, Nov 23, 2005 at 01:15:52PM -0500, Chris Gianelloni wrote:
> > > > > OK.  I've been looking at some of these issues we've been having, and
> > > > > I've been thinking of moving enewuser, egetent, and enewgroup to their
> > > > > own eclass.  This will resolve some issues with things in system, or
> > > > > otherwise early on, requiring shadow on Linux to get useradd.  Two
> > > > > examples of this are bug #113298 and bug #94745.  By putting them in
> > > > > their own eclass, we can keep from adding shadow to DEPEND in eutils,
> > > > > while still putting the dependency in the eclass that uses it.
> > > > 
> > > > i think i suggested this somewhere before, but why dont we just add
> > > > shadow to packages.build ... then it'll be in stage[123] and the DEPEND
> > > > will be a moot point
> > > 
> > > That doesn't solve the issue.
> > 
> > of course it does ... putting a package in packages.build means it will
> > be in all stages which means no package (like cronbase) will ever fail
> > again because the useradd binaries will always exist
> 
> I'm looking to minimize what is in a stage1 tarball, not increase it.  I
> would much prefer that we instead had a proper dependency tree, than
> hacking around it.  Applications that need to add users on Linux
> *should* DEPEND on shadow. They should not rely on it being already
> present.  

and when we move the user management hacks out of eclasses and into
portage itself, where do you think shadow will end up ?  in stage1 is
my guess

i wouldnt qualify shadow as a part of a proper dependency tree since
it's the ebuild itself that requires it, not the package

> Plus, your solution does not work retroactively to repair
> issues with the 2005.0, 2005.1, or 2005.1-r1 stages, while mine does.

tell users to stop using stage[12], you're already going that route :p
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] enewuser/enewgroup getting their own eclass

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

On Fri, 2005-11-25 at 19:24 +0000, Mike Frysinger wrote:
> > I'm looking to minimize what is in a stage1 tarball, not increase it.  I
> > would much prefer that we instead had a proper dependency tree, than
> > hacking around it.  Applications that need to add users on Linux
> > *should* DEPEND on shadow. They should not rely on it being already
> > present.  
> 
> and when we move the user management hacks out of eclasses and into
> portage itself, where do you think shadow will end up ?  in stage1 is
> my guess

Well, apparently with shadow in packages.build we can no longer build a
stage1 tarball from a stage3.  We also cannot bootstrap, as both of
these tasks strip a large number of USE flags.  As soon as I removed
shadow from packages.build, my builds resumed working.

> i wouldnt qualify shadow as a part of a proper dependency tree since
> it's the ebuild itself that requires it, not the package

It is required by our ebuild to build the package.  I'd call that a
dependency.  If you want to call it a dependency of the eclass or
portage or whatever, I don't care.  It is still a dependency in the
dependency tree.

> > Plus, your solution does not work retroactively to repair
> > issues with the 2005.0, 2005.1, or 2005.1-r1 stages, while mine does.
> 
> tell users to stop using stage[12], you're already going that route :p

That still will not fix the issue.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]