[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Linuxconf

On Fri, May 29, 1998 at 09:13:01AM -0500, John Goerzen Linux Expo Laptop wrote:
> > I hope to get a closer look at linuxconf soon.  Based on what I have
> > read, I have some preconceptions of what it does and want to see if
> > they are accurate or not.
> What really got me impressed was that it does not use its own database --
> it groks the REAL config files for each program.  This, I think,
> eliminates the largest problem from other similar types of systems.

Yes, that's a Very Good Thing.

> I was having troubles compiling it until somebody mentioned that it
> doesn't work with EGCS.  I took a look, and for some strange reason, g++
> in hamm is the EGCS g++ and not the GNU g++ (odd!).  I will give it a try
> with the GNU g++ soon.

This is a known issue and is supposed to soon be resolved.  (normal g++
isn't in hamm that is)

> > For better or for worse, I believe Linux is on the verge of gaining
> > mainstream acceptance.  Before that can happen though, something has
> > to make it easier for less technically adept users to configure and
> > maintain Linux (without dumbing things down, of course).  If my
> > preconceptions of linuxconf are close, it could fill this need.
> Yes, I think it looks good.  We still need to do a bit of work on ease of
> installation; particularly for those that are not familiar with the
> concept of multiple partitions.  FreeBSD has a nice "auto-fill" mode where
> it will automatically create partitions of appropriate sizes using
> whatever space is available on the disk.

Um, linuxconf is X based isn't it?  If so, it's not going to be useful as a
catch-all easy way to configure Linux because you still have to configure X. 
I have ideas how to fix that problem, but as of yet not NEARLY enough
experience with C to even begin the project on my own.

That doesn't acount for the machines on which X doesn't run..

> > How tightly dependent are the modules on the rest of the linuxconf
> > source?  More specifically, is it practical to have a linuxconf-dev
> This is one of the issues that the speaker addressed.  Currently, modules
> apparently require recompilation when a new linuxconf is released.  This
> could pose a problem for Debian, however, he said that there is going to be
> work on this and hopefully there will be a solution soon.
> My initial idea was that each package that has config info could provide a
> Linuxconf module instead of asking questions in postinst.  The problem,
> though, is with binary-all packages -- being written in C++, Linuxconf
> modules are all architecture-specific and thus will pose some problems in
> this context.  I do not know what a good solution would be at this time.
> The author will be having a session specifically on Linuxconf module
> programming tomorrow, so I will see about asking some of these questions.

This is potentially a Very Good Idea depending on what it requires.

> > type package so modules could be developed separately?  The reason I
> > ask is that if linuxconf prooves worthy and was standardized on,
> > wouldn't it make sense to eventually move the modules into the
> > packages they actually supported to avoid version skew problems.
> Yes, this could indeed pose a problem.  I assume that there are various
> header files, etc. that should go into a -dev package (again, I haven't been
> able to look at it closely yet).
> Another opportunity is to have each program also come with a
> "programname-linuxconf" package or something.  It would then be trivial to
> write a script of some sort to automatically recompile just those packages
> when necessary, I would hope.

Hopefully this will become a non-issue soon.

> I will try to compile it with the real G++ tonight and I'll hopefully have a
> lot more concrete observations for y'all tomorrow.
> BTW, the linuxconf website is http://www.solucorp.qc.ca/linuxconf

I'll give it a look.

Attachment: pgpE0tcNb5Wmz.pgp
Description: PGP signature

Reply to: