CC limited to debian-kernel as this isn't for release anymore. Sven Luther <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
