Since interactivity (eula or otherwise) is again being brought up, read through glep52 a bit, found some issues-
1) Specification doesn't actually lay out the mechanism for filtering. User tweaks what to block interactive ebuilds? 2) What ebuild phases are allowed to be interactive? Scenario being, some 'smart' ebuild dev does something interactive in pre_rm, user installs the ebuild, later on disables interactivity; the reference patch only does checks against portdb, doesn't check against vardb; meaning that it'll miss that pre_rm requires interactivity. That's also ignoring pre_inst for binpkgs that may require interactivity... hence the question of what phases are allowed? Personally, inclined to keep it as minimal as possible- for parallel execution of builds, the interactive build *must* be in the foreground, meaning you can't have two interactive ebuilds building in parallel (can, but can easily wind up with one of them stalled out waiting on input). Off the top of my head, would assume that src_unpack and pkg_setup are enough; that said, could see people wanting to abuse interactivity for src_test (xdg-utils comes to mind), and/or src_compile (kernel or uclinux configuration). So... needs narrowing down, question being "narrowed down to what phases?" ~harring
pgpqTXX9mwDuU.pgp
Description: PGP signature
