On Tuesday 23 August 2005 22:41, Paul de Vrieze wrote: > On Thursday 14 July 2005 14:37, Jason Stubbs wrote: > > On Thursday 14 July 2005 20:58, Ned Ludd wrote: > > > echo "being that no portage dev in his/her right mind would > > > ever" echo "allow interactive code in an ebuild we use bashrc tricks" > > > > Actually, I promote interactive code in pkg_config(). There's no > > standard as to what it will do, so there's no real solution other than > > telling the user and then waiting for confirmation. > > > > As for the other phases, they should of course be 100% non-interactive. > > However, a pkg_presetup() or some such couldn't go astray - as long as > > it was purely optional. It would be much better to wait until portage > > supports arbitrary per-package env for it to be of any real use though. > > Wouldn't it better suit our needs to write a configuration program that > packages can feed some custom configuration questions, and that then > spits out something that can be used by the ebuilds. This would allow > offline configuration of ebuilds etc. And something that was saved.
This limits the possibilities of what can be done, no? For example, answers determining the following questions or the selection of questions based on how the package was installed. Indeed there could be different questions based on whether it appears to be an upgrade or fresh install. If the only benefits are being able to provide a consistent interface and "offline" configuration, I don't really see the effort being worth it. A usable interface abstraction can't really be created until the requirements are known (which they're not due to pkg_config being severely underused) and batched configuration can be done by creating a text file with answers and piping. -- Jason Stubbs
pgp6pSDTt1d8Q.pgp
Description: PGP signature
