Hi!
I'm getting a lot of mails full of questions about my Linuxconf Debian
package so I've put together a little FAQ (attached).
I also want to further intergate Linuxconf into Debian but this requires
a lot of work. If you want to help me with this please contact me.
If you want t
"matthew.r.pavlovich.1" <[EMAIL PROTECTED]> wrote:
> what is the current status of linuxconf and debian?
I made a package up, which is currently in experimental because it breaks
booting, and doesn't understand includes in /etc/named, among other things.
If people woul
Processing commands for [EMAIL PROTECTED]:
> reassign 27663 linuxconf
Bug#27663: project: installing linuxconf on my maschine running Debian slink
Bug reassigned from package `project' to `linuxconf'.
> thanks
Stopping processing here.
Please contact me if you need assistan
reassign 27663 linuxconf
thanks
Runo Førrisdahl wrote:
> Farris: ~/install# dpkg -i linuxconf_1.10r34-1_i386.deb
> (Reading database ... 62852 files and directories currently installed.)
> Unpacking linuxconf (from linuxconf_1.10r34-1_i386.deb) ...
> dpkg: error processing linux
Package: project
Version: N/A
Farris: ~/install# dpkg -i linuxconf_1.10r34-1_i386.deb
(Reading database ... 62852 files and directories currently installed.)
Unpacking linuxconf (from linuxconf_1.10r34-1_i386.deb) ...
dpkg: error processing linuxconf_1.10r34-1_i386.deb (--install):
trying to
Rainer Dorsch wrote:
>
> I remembered, that there was some time ago some discussion about linuxconf on
> the list. I just picked up, that Suse will support linuxconf (beside yast) in
> Suse 6.0 (release date: end of 1998).
Please check our experimental such as
ftp://ftp.infodrom.
I remembered, that there was some time ago some discussion about linuxconf on
the list. I just picked up, that Suse will support linuxconf (beside yast) in
Suse 6.0 (release date: end of 1998).
--
Rainer Dorsch
Abt. Rechnerarchitektur e-mail:[EMAIL PROTECTED]
Uni StuttgartTel
e can't really
mandate what upstream developers do just to accomodate our choice of
configuration engine.
Also, does linuxconf handle nested syntaxes like lisp or html, or just
key/value pairs?
Using a tagged template scheme like Craig proposed wouldn't completely
solve the problem either
> "Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Wichert> [...] most files in /etc/init.d are marked as
Wichert> conffiles. But only a couple of them actually contain
Wichert> configuration-info.
Have yous seen the "/etc/sysconfig" setup in Red Hat 5.0? I wonder
if w
X-Mailer: Windows Eudora Pro Version 2.1.2
>> Mime-Version: 1.0
>> Content-Type: text/plain; charset="us-ascii"
>> To: Craig Sanders <[EMAIL PROTECTED]>, Jules Bean <[EMAIL PROTECTED]>
>> From: Shaya Potter <[EMAIL PROTECTED]>
>> Subject: Re
g file is
> constant just with a change in the "variables". It shouldn't be too hard to
> set up a example linuxconf module that shows how to set up a simple form
> that accepts input and place them into the proper slots in a model config
> file. This example module c
Previously G John Lapeyre wrote:
> It's also not uncommon to see config files which just contain perl
> code. (Majordomo comes to mind) . Probably python programs do this too.
But nobody said all conffiles should be managed by linuxconfig (or any
configuration system for that matter). A lo
On 4 Jun 1998, Andreas Degert wrote:
> If you look at config files like .emacs or /etc/profile where it's
> apparent that they use a structured language, it's much more clear
> that a configuration program can't grok each possible config file the
> user can write with an editor.
It's also
Andreas Degert <[EMAIL PROTECTED]> wrote:
> That is not the point; of course just the parsing, the syntactical
> portion, is rather easy. Else, how should a program like samba parse
> it's config files? Even if it's a complex embedded language, by
> definition its syntax can be parsed, and if it's
Raul Miller <[EMAIL PROTECTED]> writes:
> Andreas Degert <[EMAIL PROTECTED]> wrote:
> > please don't answer too quickly; if you think about it a second
> > (in the context of the thread) you will realize that I wrote about
> > syntactically and semantically correct config files that are too
> > co
Andreas Degert <[EMAIL PROTECTED]> wrote:
> please don't answer too quickly; if you think about it a second
> (in the context of the thread) you will realize that I wrote about
> syntactically and semantically correct config files that are too
> complex for the parser.
That shouldn't matter for co
Raul Miller <[EMAIL PROTECTED]> writes:
> Andreas Degert <[EMAIL PROTECTED]> wrote:
> > No, i meant you can't prevent the parser to error out on some edited
> > config files, not that it will happen with every edited config file.
>
> config files which are broken should be treated as error condit
Andreas Degert <[EMAIL PROTECTED]> wrote:
> No, i meant you can't prevent the parser to error out on some edited
> config files, not that it will happen with every edited config file.
config files which are broken should be treated as error conditions.
For example, if you put this email message i
Shaya Potter <[EMAIL PROTECTED]> writes:
> >> --This might mean that Linuxconf will error out if it can't parse the file,
> >> if you've made private changes to it. That's the tradeoff, you take a risk
> >> that you won't be able to use li
At 03:54 PM 6/3/98 +0200, Andreas Degert wrote:
>Shaya Potter <[EMAIL PROTECTED]> writes:
>
>> I was wondering if we have reached some sort of consesus on Linuxconf.
>>
>> The points that I see are
>>
>> *Linuxconf can't lose any info.
>>
Craig Sanders <[EMAIL PROTECTED]> wrote:
> On Tue, 2 Jun 1998, Shaya Potter wrote:
> > I believe linuxconf will version every change that it makes, i.e. if you
> > make changes w/ linuxconf and see that it didn't work, you can go back to
> > your previous
Shaya Potter <[EMAIL PROTECTED]> writes:
> I was wondering if we have reached some sort of consesus on Linuxconf.
>
> The points that I see are
>
> *Linuxconf can't lose any info.
> --This might mean that Linuxconf will error out if it can't parse the file,
&
I was wondering if we have reached some sort of consesus on Linuxconf.
The points that I see are
*Linuxconf can't lose any info.
--This might mean that Linuxconf will error out if it can't parse the file,
if you've made private changes to it. That's the tradeoff, you take a
the big things I requested, and from reading
> the linuxconf web pages, it seems he has added it, though I'm not
> sure how it does it. Why RCS? if it uses it's own system of just
> versioning the files, wouldn't that be good enough as well?
if it works, then yeah it's fine
On Wed, Jun 03, 1998 at 07:43:22AM +0300, Shaya Potter wrote:
> > Shaya> Also, linuxconf shouldn't be used to configure a user's
> > Shaya> personal information, such as .bashrc, .pinerc, those should
> > Shaya> be left to either the program itself like in pine
At 10:44 AM 6/3/98 +1000, Craig Sanders wrote:
>On Tue, 2 Jun 1998, Shaya Potter wrote:
>
>> Sorry for not responding directly, I only get debian-devel-digest, so I can
>> only respond to what I catch.
>>
>> I believe linuxconf will version every change that it make
At 12:46 PM 6/2/98 -0500, Manoj Srivastava wrote:
>Hi,
>>>"Shaya" == Shaya Potter <[EMAIL PROTECTED]> writes:
>
> Shaya> Also, linuxconf shouldn't be used to configure a user's
> Shaya> personal information, such as .bashrc, .pinerc, those shou
On Tue, 2 Jun 1998, Joel Klecker wrote:
> At 07:40 -0700 1998-06-02, Craig Sanders wrote:
> > BTW, the fact that you don't understand sendmail doesn't prevent
> > others from doing so. sendmail really isn't that difficult, and is
> > simpler in some ways because you don't have multiple config file
On Tue, 2 Jun 1998, Shaya Potter wrote:
> Sorry for not responding directly, I only get debian-devel-digest, so I can
> only respond to what I catch.
>
> I believe linuxconf will version every change that it makes, i.e. if you
> make changes w/ linuxconf and see that it didn
At 07:40 -0700 1998-06-02, Craig Sanders wrote:
>BTW, the fact that you don't understand sendmail doesn't prevent others
>from doing so. sendmail really isn't that difficult, and is simpler in
>some ways because you don't have multiple config files scattered across
>multiple directories.
FUD, exim
sendmail (which still is an industry standard smtp daemon) in favour
> of simpler to configure replacements. I guess we can live with that.
>
> Of course, switching MTA's involves other decision parameter
> than a simplistic pointy clickey configuration, but I shall no
On Tue, Jun 02, 1998 at 12:46:02PM -0500, Manoj Srivastava wrote:
> Shaya> Also, linuxconf shouldn't be used to configure a user's
> Shaya> personal information, such as .bashrc, .pinerc, those should
> Shaya> be left to either the program itself like in pine, or to
Craig Sanders <[EMAIL PROTECTED]> wrote:
> BTW, the fact that you don't understand sendmail doesn't prevent others
> from doing so.
The problem with sendmail isn't that it's difficult to understand, it's
that it rewrites headers, by default. This introduces a whole class of
rather subtle bugs tha
On Tue, Jun 02, 1998 at 03:59:22PM +0100, Jules Bean wrote:
> > yes, that's a perfect solution.for those who choose to use exim. it
> > does absolutely nothing at all for those who prefer to use sendmail.
>
> True. But I was answering the suggestion (chopped, unfortunately, which
> was fooli
Hi,
>>"Shaya" == Shaya Potter <[EMAIL PROTECTED]> writes:
Shaya> Also, linuxconf shouldn't be used to configure a user's
Shaya> personal information, such as .bashrc, .pinerc, those should
Shaya> be left to either the program itself like in pine,
.
*grin*
provocative, apparently.
That's the second time I've been misunderstood, so I'll explain..
The initial post was suggesting (I'm sorry, I don't have the exact words)
that somehow a linuxconf front-end was the correct solution to the fact
that Linux email is hard t
Hi,
>>"Jules" == Jules Bean <[EMAIL PROTECTED]> writes:
Jules> This sounds foolish to me.
Hmm, provocative words.
Jules> The solution is to switch to a better designed mailer (exim
Jules> springs to mind) with easier to manage configuration.
This seems to imply that linuxconf
it needs to read and parse the config file, allow the user to manipulate
>it, and then write it back out again (if the user chooses to save any
>changes) WITHOUT losing any information, including comments and the
>order of the comments.
>
I believe linuxconf will error out if it c
On Wed, 3 Jun 1998, Craig Sanders wrote:
> On Tue, 2 Jun 1998, Jules Bean wrote:
>
> > > The solution of course is to extend the m4 stuff to support all the
> > > things linuxconf does, but that's not so easy. Also, note that
> > > slackware didn't at
On Tue, 2 Jun 1998, Rev. Joseph Carter wrote:
> > RE: sendmail.cf
> >
> > IMO, linuxconf should manage sendmail.mc rather than sendmail.cf.
>
> That would be more reasonable, however not all that sendmail can do is
> supported with the m4 rules and such. Not at the
On Tue, 2 Jun 1998, Jules Bean wrote:
> > The solution of course is to extend the m4 stuff to support all the
> > things linuxconf does, but that's not so easy. Also, note that
> > slackware didn't at last look have m4 sendmailconfig. Another
> > example of
On Tue, 2 Jun 1998, Jules Bean wrote:
> >> So support the full grammar of the file.
> >
> > debian currently has 1956 packages. most of them require a config file.
> > do you think having that many individual parsers is viable?
>
> Ooh.. debian has 1956 packages. Do you think having that many p
Sorry for not responding directly, I only get debian-devel-digest, so I can
only respond to what I catch.
I believe linuxconf will version every change that it makes, i.e. if you
make changes w/ linuxconf and see that it didn't work, you can go back to
your previous configuration or any o
Ok, I see their has been a lot of talk on if the way linuxconf does its
thing is good for debian.
first things first, a user doesn't have to use linuxconf. If a user wants
to edit the file by hand they can use the existing tools that we have. Even
those aren't perfect, if I edit my s
On Tue, Jun 02, 1998 at 11:14:45AM +0100, Jules Bean wrote:
> > The solution of course is to extend the m4 stuff to support all the things
> > linuxconf does, but that's not so easy. Also, note that slackware didn't at
> > last look have m4 sendmailconfig. Another e
On Tue, 2 Jun 1998, Rev. Joseph Carter wrote:
> > IMO, linuxconf should manage sendmail.mc rather than sendmail.cf.
>
> That would be more reasonable, however not all that sendmail can do is
> supported with the m4 rules and such. Not at the moment at least. Sendmail
> is t
hen it
> > > should not edit the file.
> >
> > With the exception of sendmail.cf, linuxconf does this.
>
> so i can make any arbitrary change to any config file which linuxconf can
> work with, and linuxconf will:
>
> - not freak out because of some weirdn
--On Tue, Jun 2, 1998 11:18 am +1000 "Craig Sanders" <[EMAIL PROTECTED]> wrote:
> On Mon, 1 Jun 1998, Raul Miller wrote:
>
>> > > The proper solution would be to fix the parser.
>> >
>> > unfortunately, this means placing arbitrary restrictions on the
>> > config filesanything which hasn't b
I don't want there to be any overlap on packaging, but I hear now that
someome else is packaging linuxconf, but I don't know who. I am (was)
packaging it for libc6, and I had to make a couple of changes because
either it's glibc support is broken or our header files are broken.
CTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Debian and Linuxconf (again :-) )
On Sat, 3 May 1997, Shaya Potter wrote:
> Since I have had a lot of time off for exams, I have been thinking about
> what whould be neccesary for Linuxconf and Debian to coexist. (and a
> m
I am almost finished with my AP's, only having Biology tomorrow. During
my free time I have thaught up a way that may allow us to use Linuxconf,
and all of it's starting/stoping features w/o replacing init. The author
of linuxconf liked the idea so it looks like we might have an e
51 matches
Mail list logo
