Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
CC limited to debian-kernel as this isn't for release anymore.
Sven Luther <sven.luther@wanadoo.fr> writes:
> On Sat, Aug 12, 2006 at 12:46:18AM +0200, Goswin von Brederlow wrote:
>> And actualy just recently the first one was uploaded to non-free
>> including udebs:
>>
>> http://ftp.debian.org/debian/pool/non-free/f/firmware-non-free/
>>
>> Now the DAK must be configured to create a
>> dists/sid/non-free/debian-installer/ subdir and index files for the
>> udebs. But I feel we are already one step closer to the goal.
>>
>> Step 1: Create non-free udebs. *checked*
>> Step 2: Add DAK config *waiting for ftp-masters*
>> Step 3: Add D-I support
>
> I would propose something even more advanced, and not put the kernel .udebs
> into the main debian-installer thing, but into a separate section.
>
> The way i envision this, we would create a debian/sid/main|non-free/kernel
> section, where the kernel .udebs would be hold, and we start building them
> from the main kernel package.
>
> Ideally, we would go a step further, and have
> debian/sid/main|non-free/kernel/<flavour> sections, so we can split the kernel
> .udeb packages in a finer grain, and each running installer will only be
> seeing the modules corresponding to the kernel flavour he is running.
What for? The installer always needs the installer udebs. Having the
kernel udebs in another section just means more files to generate and
to download that can go wrong. It saves nothing.
Splitting the udebs by flavour would save a few bytes on the Packages
file but the only affect that has would be a few bytes less downloaded
(inconsequential) and a few bytes less ram used (if you are that low
then you have problems anyway).
If you want the user to only see the kernel components that match the
running kernel then filter them in the display. I don't think
splintering the Index files into tons of sections is the way to go
there. Also think about what that would mean for a newly added kernel
flavour in terms of delays till the DAK gets reconfigured for a new
section.
> This was my proposal from the start, and if you think down to it, it is the
> best solution for all the kernel/d-i related problems, and would allow to
> complete the work started with the common packaging, into a solution where
> there will be only a single package build, easily doable on the usual buildd
> network, will allow the most flexible solution for abi bumps and security
> upgrades.
The layout of the Index files and sections used has absoluetly no
effect on either abi bumps nor security nor in any way the package
building. Extra sections just means much more work for the DAK with
little to no benefit. I don't even consider that a good
solution. Quite opposite. The requirement of a new section for a new
kernel flavour would create a lot of delays for the kernel-team when
adding a new flavour.
> But then, i was not able to complete these ideas, due to my mothers illness
...
And there you go again. STOP IT PLEASE. It is totaly off-topic.
...
> So, you see, if i am angry and hurt, and you dislike me repeating it always,
> you know who to blame.
You for repeating it over and over. With every repetition the
precieved blames shifts a little bit to your side until all people see
precieve is that you are to blame.
MfG
Goswin
Reply to: