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: _pleeeease_ > 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
