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