Re: About using Linuxconf
-----BEGIN PGP SIGNED MESSAGE-----
At 01:20 PM 12/29/96 +0900, Richard G. Roberto wrote:
>
>OK. Now I think I get it. So what I was suggesting isn't that
>far off the mark. I was suggesting having a utility that
>dynamically built the dropins for the packages. My assumption
>was also that one could use linuxconf to modify package behavior
>(and thus the dropins) so I also suggested that this utility
>should be able to dynamically construct the "standard" package
>conf files from the dropins in the event a user wanted to purge
>linuxconf. That way packages could check some state flag or
>something to see if linuxconf was active and just run the utility
>to create (or update?) the dropins.
I like this idea, maybe we can have it be a standard that every package
that now installs init.d scripts, also contains a special file, similar to
control, that contains information such as: what files to monitor and other
information linuxconf or any other admin tool needs. Then any tool can use
this data to make their "plugins".
We can make this even more standard by having all these programs call a
"configure" program at the end of their installation. This configure
program will be in the same place for any admin tool, such as linuxconf,
and the "configure" program will take the data that was put into the
database from the special file I mentioned. We can then use linuxconf, or
any other admin tool you want, all you have to have is a "configure"
program and the packages will work as is.
This has the advantage of the only thing that has to be changed when we get
a new admin tool is perhaps a few new fields for the special file and a
"configure" for that tool. We can keep the init.d scripts we have now to
for the start and stop fields.
This is a bad example, but anyways
START:/etc/init.d/networks start
STOP:/etc/init.d/networks stop
MONITOR:/etc/inet.conf;/etc/services
and we can look at the example dropins for more fields.
>
>Now this seems to make sense. We have a similar problem with
>base-files. If a user has modified his/her passwd or group
>files, base-files gives you the choice to keep them instead of
>installing the new files. This isn't good enough however. If I
>have local mods in these files, I'm going to say "No" and keep
>the files. But then I don't get the new additions made to
>the base-files package. The same would hold true for linuxconf
>dropins. Instead of devising some way to make it possible to
>upgrade linuxconf dropins (with package tags or something), it
>may just be better to devise a database style approach for all
>config data. That way Linuxconf could use that for dropin
>management just as other packages could use it for their own
>configuration management. Data could easily be tagged in such a
>case to identify where it came from (i.e. the package or a user,
>etc.) and management is much easier.
I think that is what I said above. This was not what I originally was
thinking of, but now I think it is a GREAT idea, thanks.
>
>Now I think I get it. And now I think that linuxconf isn't the
>answer, because we'd still need to develope some Debian specific
>way of managing dropins and upgrades, etc. What Bruce is
>proposing makes much more sense to me now. I think that a
>linuxconf package would be a great idea -- especially with a way
>to manage dropin files, etc. the way we've been discussing.
Yes.
Shaya
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMsb95tnmB2S2D+tlAQHAvgQAjAgpS5iW1xoYqNwqxTK3PI7YHv18mCPS
BSKSNzJZiof7Y60ScQ8LgCw6LyS27uWfa0EOjDUSomHBJk/6tnmQRUYeL7xk4wD0
LCj1EvkVUh6zqs9ga+JDK8o4fvZxEdj6A3PmRcG6RDnbrvHP2U+lUpX+cMvAZlQa
0Snjsv26uWw=
=yRoT
-----END PGP SIGNATURE-----
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: