Re: [gentoo-dev] GLEP 27 Proposal - Feedback Requested
Hello Mike, Am Dienstag, 30. Mai 2006 05:29 schrieb Mike Kelly: I'm Mike Kelly, one of the SoC-ers. I'll be working on GLEP 27 for the summer. Right now I'm looking for some basic feedback on my proposal. In particular, I know that at one point there was a push for the user info files to be XML, but I think it may be easier to implement them as simple shell variable files (like /etc/conf.d/*), since my plan was to write the core of the implementation in shell (e.g. as an eclass). From your proposal: - Add code to the eutils.eclass which will detect if the installed version of portage supports the new system, notifies the operator that the current ebuild is using depreciated code, and properly add the user using the new system's code. This would check for the proper EAPI version to know when to execute the new code instead. As a member of Release Engineering who encountered already a problem with user-management code in eutils.eclass, i beg you: _plase_ don't add it to that eclass. Instead, create a new eclass 'euser' or something similar and add it there. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 27 Proposal - Feedback Requested
On Tue, May 30, 2006 at 09:14:01AM +0200, Danny van Dyk wrote: Hello Mike, Am Dienstag, 30. Mai 2006 05:29 schrieb Mike Kelly: I'm Mike Kelly, one of the SoC-ers. I'll be working on GLEP 27 for the summer. Right now I'm looking for some basic feedback on my proposal. In particular, I know that at one point there was a push for the user info files to be XML, but I think it may be easier to implement them as simple shell variable files (like /etc/conf.d/*), since my plan was to write the core of the implementation in shell (e.g. as an eclass). From your proposal: - Add code to the eutils.eclass which will detect if the installed version of portage supports the new system, notifies the operator that the current ebuild is using depreciated code, and properly add the user using the new system's code. This would check for the proper EAPI version to know when to execute the new code instead. As a member of Release Engineering who encountered already a problem with user-management code in eutils.eclass, i beg you: _plase_ don't add it to that eclass. Instead, create a new eclass 'euser' or something similar and add it there. Commented in irc re: this, but eclass doesn't really fly- if it's implemented strictly in an eclass, portage has no way of easily reverting the changes (mainly cause it's not aware of 'em) if the build fails, thus the user/group isn't needed. Same for unmerging. Further, if implemented strictly as a trick in one of the ebuild phases, setup is the likely place- means that setup cannot be deprived to non-root for running it (thorn in the side for trying to depriv all phases). So... need it higher up then implemented in one of the ebuild phases. :) ~harring pgpDaQe1Exygv.pgp Description: PGP signature
Re: [gentoo-dev] GLEP 27 Proposal - Feedback Requested
On Monday 29 May 2006 23:29, Mike Kelly wrote: In particular, I know that at one point there was a push for the user info files to be XML not really, it was just an idea i had at the time ... ive been over it a few times since with the portage guys and it makes no real sense to do it in xml also, current GLEP 27 should say nothing of xml , but I think it may be easier to implement them as simple shell variable files (like /etc/conf.d/*), using shell variables just leads to quoting problems since my plan was to write the core of the implementation in shell (e.g. as an eclass). i fail to see where eclasses play any role in the scheme of things the point of having all the logic in portage is that ebuilds need not care about anything My proposal is available at: http://www.pioto.org/~pioto/gentoo/soc2006/glep27-proposal.txt. Any feedback would be appreciated; I wanna get things started on the right foot. we shouldnt give a way to add extra custom options since we're back to square one in terms of portability (useradd is only used on GNU systems, not Darwin/BSD) the current format last time i bugged the portage peeps was simple: key: value -mike pgpysvCYSlNeJ.pgp Description: PGP signature
[gentoo-dev] GLEP 27 Proposal - Feedback Requested
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I'm Mike Kelly, one of the SoC-ers. I'll be working on GLEP 27 for the summer. Right now I'm looking for some basic feedback on my proposal. In particular, I know that at one point there was a push for the user info files to be XML, but I think it may be easier to implement them as simple shell variable files (like /etc/conf.d/*), since my plan was to write the core of the implementation in shell (e.g. as an eclass). My proposal is available at: http://www.pioto.org/~pioto/gentoo/soc2006/glep27-proposal.txt. Any feedback would be appreciated; I wanna get things started on the right foot. Thanks! - -- Mike Kelly Happiness adds and multiplies as we divide it with others. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEe7wEokMzJ47YCzoRAps/AJ9pET/7BBjwiouJeIeVLPj91Dau0wCeM+jH KyJjXcpv2jMwBvNZjvYqr3w= =b+Bf -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
