| 1 |
On 7/7/07, Steve Long <slong@××××××××××××××××××.uk> wrote: |
| 2 |
> I'm ofc not including fetch-restricted which also require interaction, |
| 3 |
> although that is standardised enough for a script to deal with[1]. Having |
| 4 |
> found this for games, I can deal with that too ofc, but I still think the |
| 5 |
|
| 6 |
I'm not sure whether special license agreements are a legitimate case |
| 7 |
for interactivity in some ebuilds, but I can tell you the einput |
| 8 |
eclass was intended to be used only in pkg_config(), meaning the only |
| 9 |
time the user would ever encounter einput is when they specifically |
| 10 |
run "emerge --config foo" after installation, and even then it would |
| 11 |
be only in a handful of ebuilds that actually need einput's services. |
| 12 |
Burdening the user with the prospect of interactivity in any other |
| 13 |
ebuild phase does seem to go against the Portage philosophy, so I feel |
| 14 |
that einput.eclass is an edge case tool at best. |
| 15 |
-- |
| 16 |
gentoo-dev@g.o mailing list |
Archives