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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
