public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] restricting phases where enew{user,group} is allowed
@ 2011-11-24  0:31 Mike Frysinger
  2011-11-24 13:24 ` Gilles Dartiguelongue
  2011-11-26  6:42 ` Mike Frysinger
  0 siblings, 2 replies; 3+ messages in thread
From: Mike Frysinger @ 2011-11-24  0:31 UTC (permalink / raw
  To: gentoo-dev

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

currently we blacklist certain phases (which is largely based on EAPI=0 and 
blocking src_*) for enew{user,group}.  moving forward, ferringb suggested we 
invert this into a whitelist of allowed phases.

afaict, the blacklisting + dev documentation has done a good job of 
restricting calls to three places: pkg_{setup,preinst,postinst}.  so inverting 
the logic should largely be safe.  on the off chance it isn't, i think letting 
the ebuild `die` and getting it fixed up via bug reports is acceptable (i 
grepped through the tree a bit and looked sane).

moving beyond that, i'd like to also ban pkg_postinst usage.  the trouble with 
using this phase is that `die` isn't fatal because the package has already 
been merged to $ROOT, so there's no going back.  and while logically i can see 
that people might prefer pkg_postinst vs pkg_preinst (no point in creating a 
user/group if the pkg isn't actually yet merged), for all real world usage, 
there's no need to delay it, and it makes the ebuilds a bit more robust as 
errors get caught before things get merged to $ROOT.  i believe the 
documentation has always recommended pkg_setup and pkg_preinst anyways.

moving even beyond that, i'd like to update the documentation to push people 
to prefer pkg_preinst.  if your package doesn't require the user/group to be 
available at compile/install time, then there's no need to use pkg_setup.  
this improves the use case of attempting to install a package from source, 
things failing for whatever reason, and then the pkg is never actually 
installed, but the user/group is left behind.

any feedback before i implement ?
-mike

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [gentoo-dev] restricting phases where enew{user,group} is allowed
  2011-11-24  0:31 [gentoo-dev] restricting phases where enew{user,group} is allowed Mike Frysinger
@ 2011-11-24 13:24 ` Gilles Dartiguelongue
  2011-11-26  6:42 ` Mike Frysinger
  1 sibling, 0 replies; 3+ messages in thread
From: Gilles Dartiguelongue @ 2011-11-24 13:24 UTC (permalink / raw
  To: gentoo-dev

Sounds like a sane change.

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [gentoo-dev] restricting phases where enew{user,group} is allowed
  2011-11-24  0:31 [gentoo-dev] restricting phases where enew{user,group} is allowed Mike Frysinger
  2011-11-24 13:24 ` Gilles Dartiguelongue
@ 2011-11-26  6:42 ` Mike Frysinger
  1 sibling, 0 replies; 3+ messages in thread
From: Mike Frysinger @ 2011-11-26  6:42 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: Text/Plain, Size: 723 bytes --]

On Wednesday 23 November 2011 19:31:11 Mike Frysinger wrote:
> currently we blacklist certain phases (which is largely based on EAPI=0 and
> blocking src_*) for enew{user,group}.  moving forward, ferringb suggested
> we invert this into a whitelist of allowed phases.
> 
> afaict, the blacklisting + dev documentation has done a good job of
> restricting calls to three places: pkg_{setup,preinst,postinst}.  so
> inverting the logic should largely be safe.  on the off chance it isn't, i
> think letting the ebuild `die` and getting it fixed up via bug reports is
> acceptable (i grepped through the tree a bit and looked sane).

committed:
http://sources.gentoo.org/eclass/user.eclass?r1=1.10&r2=1.11
-mike

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-11-26  6:43 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-11-24  0:31 [gentoo-dev] restricting phases where enew{user,group} is allowed Mike Frysinger
2011-11-24 13:24 ` Gilles Dartiguelongue
2011-11-26  6:42 ` Mike Frysinger

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox