Gentoo Archives: gentoo-dev

From: Mike Frysinger <vapier@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] restricting phases where enew{user,group} is allowed
Date: Thu, 24 Nov 2011 00:31:42
Message-Id: 201111231931.11919.vapier@gentoo.org
1 currently we blacklist certain phases (which is largely based on EAPI=0 and
2 blocking src_*) for enew{user,group}. moving forward, ferringb suggested we
3 invert this into a whitelist of allowed phases.
4
5 afaict, the blacklisting + dev documentation has done a good job of
6 restricting calls to three places: pkg_{setup,preinst,postinst}. so inverting
7 the logic should largely be safe. on the off chance it isn't, i think letting
8 the ebuild `die` and getting it fixed up via bug reports is acceptable (i
9 grepped through the tree a bit and looked sane).
10
11 moving beyond that, i'd like to also ban pkg_postinst usage. the trouble with
12 using this phase is that `die` isn't fatal because the package has already
13 been merged to $ROOT, so there's no going back. and while logically i can see
14 that people might prefer pkg_postinst vs pkg_preinst (no point in creating a
15 user/group if the pkg isn't actually yet merged), for all real world usage,
16 there's no need to delay it, and it makes the ebuilds a bit more robust as
17 errors get caught before things get merged to $ROOT. i believe the
18 documentation has always recommended pkg_setup and pkg_preinst anyways.
19
20 moving even beyond that, i'd like to update the documentation to push people
21 to prefer pkg_preinst. if your package doesn't require the user/group to be
22 available at compile/install time, then there's no need to use pkg_setup.
23 this improves the use case of attempting to install a package from source,
24 things failing for whatever reason, and then the pkg is never actually
25 installed, but the user/group is left behind.
26
27 any feedback before i implement ?
28 -mike

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies