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