Re: Linuxconf again and again (was: purposes)
I agree completely with you, linuxconf is not acceptable, it's entirely
design is flawed. We need a system that can grow, and be very flexible.
I was thinking some sort of system where a packages communicate with a
frontend, they tell it what variables the package has available and provides
hints on how the configuration is presented to the user.
The frontend should be completely unaware of the details of the
configuration files for each package.
If we could agree on some sort of protocol to transmit configuration
settings it would be a step in the right direction.
On Fri, Jun 18, 1999 at 10:36:44PM -0700, Aaron Van Couwenberghe wrote:
> Hello all -
> I know many of you will not like what I have to say here, but I've looked
> at the problem extensively, and *know* that any linuxconf (or other
> configuration system currently out there) based system will not cut it for
> A much more aggressive strategy must be taken, possibly involving usurping
> the way dpkg does things right now. Simply put, linuxconf is *not*
> acceptable for networked installation profiles and remote configuration
> management, but this is what 75% of end users will want an admintool for.
> And no, --(get|set)-selections with some tcp hack and batch config with
> linuxconf wouldn't tie it together well enough either.
> I may seem like a naysayer. Yes, I've looked at doogie's dconfig, and it's
> quite nice, but I still think something more is needed (besides -- why
> create and enforce yet another config management infrastructure if it's
> not entirely different?)
| Stephen Crowley | Debian GNU/Linux |