Summary of dev meeting

[Jasper Huijsmans]

Hey all,

I'll try to give a summary of what I believe was discussed at the
meeting with the conclusions. Remember, this is my interpretation,
please correct me if I'm wrong. 

Also I was hoping perhaps we could discuss the unresolved issues some
more. Could be done on IRC as well.

Warning: it's a pretty long e-mail.


Ok, csm gave us two problems to solve:

#1 kernel installs may never wipe out a working system, so we need to
fix lunar to make backups. This must be done automatically.

#2 Asking questions is bad. It must be possible to do unattended
installs and upgrades.


KERNEL
======

a) headers

While discussing kernel versioning, the use of kernel headers was
brought up. The kernel headers must be the ones glibc was compiled
against.

Niki suggested to let glibc copy the headers over after it compiled
against them. I suggested to use a separate kernel header package.

The advantage of the kernel-headers package is that you have a clearly
defined set of headers and once we're happy with 2.6 and get all/most
packages building against 2.6 headers we can simply update the headers
package.

CONCLUSION on kernel headers:
In the end, most devs agreed with the separate header solution. csm
appointed elaine as the one to create the module and niki, Moe, Rattler
and nestu to help testing.

b) kernel versions and backup

We agreed immediately that special support for kernel versioning should
be added to core.

Different kernel versions must _not_ be done using 'normal' module
versioning (linux/2.4.22), but they have to be different modules:
linux-2.4.22/, linux-grsec-2.4.22/, etc. 

Sofar suggested to keep track of installed kernel versions in
/var/state/lunar/kernel and csm proposed to use a special directory in
the module-dir to hold the bootloader stanza. This is described in more
detail in rodzilla's mail, so I won't go into that.

CONCLUSION on kernel install, versioning an backup:
Conclusion is not as clear as for the headers. Implementation still
needs work. Sofar should be in charge here, rodzilla offered to work on
the bootmanager script. Elaine already did some work on the backup
issue, so I guess she will be involved as well. I'd be happy to test and
help out with this. 

Personal note: I see one problem with backing up a kernel. First of all
backing up is only necessary when the current kernel is the same as the
newly build kernel. It is relatively simple to move the old kernel to
*.old and put that in the bootscript. However, the old and new kernels
will look in the same location for modules, so renaming the old modules
dir will not work. In the case the new kernel is broken and the old
kernel depends on one or more modules for some critical part of its
operation, the user is screwed. This does seem a very unlikely scenario,
though and I believe we can get away with ignoring this issue.

Another thing, that did not get discussed, is the installation of
external kernel modules, like the NVIDIA driver. They install to the
current running kernel. Should we have special versioning support here
as well?

This is all rather complex so I'm sure I missed some issues here. 


LUNAR ASKING QUESTIONS
======================

Although we see the need for unattended installs, nobody wants to lose
lunar's current cutomizability, so asking questions must be made
optional. By default lunar should not ask questions.

Several ideas floated around about adding a global ASK option and having
commandline parameters. Sofar suggested to let lin -r handle the
questions and have prefilled dependency info available on the ISO. lunar
fixdepends will rebuild the database based on installed modules (did I
understand this correctly?).

CONCLUSION on lunar questions:
I don't think there was a final conclusion yet. We agree questions
should be off by default and we agree there should be a way change that
behaviour. Current proposal is to prefill the depends info on the ISO.

Let me add some of my thoughts on this issue. 

The CONFIGURE queries are rather simple I'd say. I like the suggestion
to not ask questions unless the user specifies lin -r.

For the optional depends issue, the prefill option does not feel quite
right to me. Like I said yesterday, it feels wrong to handle a package
management issue outside the package management system.

Also, what happens when a module get an extra optional dependency? Or
when the user runs lunar fixdepends?

To me it seems that if the optional_depends function could take an extra
parameter to specify a default, just like query, lunar would always do
the right thing.


Ok, that's it. Please correct me if I draw the wrong conclusions and add
missing issues.

Oh, and for those who didn't read niki's log, let me finish with this
quote: 

  <csm> oh and one more thing!
  <csm> I think we have a fabulous developer group

I think I agree ;-)

	Jasper