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 |