>
> Packages should be able to install without any question asked. Default
> config files must be provided as well as default config databases.
Agreed. However, in a very few cases an answer from the user is needed.
For example, you must know the hostname of the computer and the type
of connection it has. Using a default value is a wrong choice.
This is what Windows does. I have an ethernet connection and still Windows
tells me sometimes that I need to configure my modem to connect to the
Internet. I guess it assumes that a direct ethernet connection is not the
right way to connect to the Internet...
> Which brings to my mind that you need several other fields:
>
> Default, SystemDefault, UserDefault, Level, Arch, Type.
>
> Esspecially the type is important, otherwise any GUI to edit the
> database won't know what to ask for.
>
Yes, many fields are needed. I did not go into the design of the database.
As I said, my database engine does not make any hardcoded assumption on
the number/names of fields in the database. That's an open question that
needs to be worked out.
> The kernel-config style is just for frontends, a lot of the proposal
> also describes the backend, which would collide with your
> approach. Your example looked very complicated, the qvwm example you
> did looks a lot nicer. But I especially miss default values and types
> of questions.
>
I guess the only point of collision is that you used shell scripts where I
used templates. I explained why I prefer templates. Other than that,
I think my generator fits perfectly within your framework. You defined
a whole framework and my generator is just one small piece of the whole
system.
And my generator can use default values and types without problems. That's
not where the difference lies.
[regarding a one-way system]
> And thats the problem. Thats what realy kills you when using SuSe and
> yast as a debian user. Debian should handle it smarter.
I agree completely. But parsers are difficult and a two-way system will
take time to be built. In some cases parsers are straightforward and
should be provided but in others it is trickier. I think that a one-way
system designed to become a two-way system eventually is the right way
to proceed.
Regards,
Fernando
