webapp-config should be updated to handle such situation more gracefully, so
why don't you file a bug about this? Is that all you have wrt "all the ways
in which webapp-config is broken"? If so, that's not really much of a
justification of the broad claim ciaranm has made as a QA project member.
I only encountered the problem the day before yesterday, and hadn't
gotten around to filing the bug yet. I assure you that I intend on
doing so.
And please, don't tell me this is a feature. It breaks noninteractivity
for every "webapp" in the entire tree.
What kind of non-interactivity? What's this universal non-interactivity
blurb of yours and ciaranm's about? There's no such thing when it comes to
configuration. If you want automated "configuration", then please use
Windows and stop moaning. If you don't want to read manpages or at least
--help, then please use Windows as well. If you want to use non-default
setup, then you need to change default values, that's what common sense
dictates at least. And don't use the (non)-interactivity magical formular in
a context where it has zero sense.
No! You are completely missing the point. The non-interactivity of
which we speak is the idea that when you emerge some package, it is
perfectly reasonable (and in fact should be required) to expect that
package to install to your userland with no further prodding. There
should be no USE collisions which cause the emerge to die. There should
be no default configuration which will break other packages in the tree
by default.
Note that in no way am I talking about auto-configuration, as that would
be silly. The example problem with webapp-config which I have described
here forces a user to intervene to get packages to install to the proper
location. This is not desirable.
Basically, I really don't see why webapp-config can't have some logic
built in which makes it smart enough to figure out which webserver
somebody is using.
-Steve
--
gentoo-dev@gentoo.org mailing list
