Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i

[Sven Luther <sven.luther@wanadoo.fr>]

On Fri, Nov 03, 2006 at 09:24:28PM -0300, Otavio Salvador wrote:
> > Yeah, but adding them to the image is not always the best solution, loading
> > afterward may be a better way.
> >
> > Also, there may be another future for .udebs out there than just for d-i use,
> > altough i know the d-i folk doesn't like this :)
> 
> You mean for embeed systems? Yes. I agree with you.

Embedded systems, and stuff like the ghost-like image which Xavier should have
been working on, based on gparted and partimage, which got lost because he
ended up having to rewrite gparted in C.

> But for we start to allow more widly use of udebs there're some issues
> that need to  be in better shape like:
> 
>  - debian-cd
>  - bridney
>  - d-i itself
> 
> otherwise can be a lot harder to make a d-i release to happen.
> 
> Another alternative can be use something like edeb for embeed
> devices. That would be a clear option then use udeb for both. Using
> another group of packages would make both worlds happy and make both
> team lives easier. One wouldn't affect the other with their respective
> decisions.

My belief is that, once post etch we have support for multiple udeb sources,
we should split the archive thus :

  - the libraries and support package (like parted) in a generic archive.
  - the debian-installer packages in a debian-installer archive.
  - the kernel modules in a separate archive, of which there would be one by
    kernel version (upstream+abi), so as to keep d-i images alive even when
    new kernel versions are pushed in the archive. Further separation into
    flavours may help low memory systems on arches with a lot of flavours.

Then alternative projects can add to the geenric package they need, and
implement their own archive for their own project, without influencing d-i,
and everyone is happy.

Hard-core embedded guys will want to use their own stuff, but semi-embedded
folk with less need for fine-tuned builds will be able to take huge profit
from this.

But let's discuss this post etch. I am thinking of doing a fosdem presentation
of my ideas, preferably with proof of concept, which should satisfy all the
need for discussion and implementation details, and this happening at the
start of the etch+1 devel cycle will make sure we can think about it without
being in a rush.

Friendly,

Sven Luther