Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
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
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
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.