Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther <sven.luther@wanadoo.fr> writes:
> On Sat, Aug 12, 2006 at 07:46:16PM +0200, Goswin von Brederlow wrote:
>> Sven Luther <sven.luther@wanadoo.fr> writes:
>>
>> >> 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.
>> >
>> > The installer needs the installer .udebs of the flavours it is using, but
>> > hardly any others. This mean we would save on memory space used to hold the 3
>> > in-memory copy of the Packages file.
>>
>> -rw-r--r-- 1 reprepro nogroup 187K Aug 11 04:53 dists/sid/main/debian-installer/binary-amd64/Packages
>>
>> Is that really a problem? If so then work on reducing the number of
>> copies from 3 to 1 plus a compressed one. You could also filter out
>> kernel modules for other flavours while downloading the file prior top
>> saving it. For more space filter out all the udebs already installed too.
>>
>> Having all the udebs in one Packages file is convenient for
>> debian-installer when building, for debian-cd, for mirror scripts and
>> so on. Don't forget that.
>>
>> And don't forget that the businesscard or netinst CDs have filtered
>> Packages files for the udebs with only the right udebs in there. Only
>> the netboot and full CD images waste those few Kb.
>>
>> >> 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).
>> >
>> > But it would make space for a more fine-grained .udeb classification, which
>> > would in turn result in a considerable memory and bandwidth saving, as only
>> > the modules really used are downloaded.
>> >
>> > Furthermore this will allow the kernel .udebs to be moved into the common
>> > kernel package, without costing the installer folk any flexibility, as they
>> > will not have need to balance the module .udebs and thus keep control of them.
>>
>> More udebs increases the Packages files. That works contrary to what
>
> Indeed. The proposal to split the packages file in a per flavour kernel
> repository comes directly from the need to counterbalance this augmentation of
> the number of packages.
So instead of having 5 module udebs for my ONE generic kernel I get
200? For say amd64 it would be a big step back.
How many archs with flavours are we talking about anyway? I think m68k
has 3 flavours and ppc some and every other archs has a generic
flavour or drivers buildin already.
> Also, do you really need a gazillion of not-for-your-hardware modules
> installed ?
All my hardware (that includes m68k) has absolutley 0 problems with
that. They will be installed in D-I and they will be installed on the
finished system. No point breaking my neck to get less installed
during D-I.
>> you want (save space). As for saving download bandwith, saving 1MB of
>> udebs compared to the 500-2000MB debs of a normal install is quite
>> incosequential. You might be optimizing at the wrong end here.
>
> Indeed.
So why then do you want to split module udebs?
You just agreed that downloading the module udebs is inconsequential
given their size. You agreed that more udebs increases the Index files
which is bad.
So all I'm left with is that you don't end up with as much modules in
the ramdisk. Something I find irelevant unless you talk about the
low-mem flavour.
Is the space taken up by the installed modules your actual argument
for having finer grained module udebs?
...
>> You can already do that. Just because the modules are not copied into
>> udebs at the end does not mean you can't pretend. Just imagine they
>> get copied and do all your magic. After that you have a set of modules
>> and the depmod file for them that D-I uses to split modules into
>> udebs.
>
> "the depmod file that D-I uses to split modules into .udebs". You must be
> living in another planet than me. Right now the modules are split manually, in
> a stupid painstakingly repetitive and time-consuming way. And you can't even
> per-arch/subarch override properly the default choice done in kernel-wedge.
Last I used it, and that is some time ago, the dependencies where
automatically checked on build. Maybe someone broke that but that
could be repaired easily enough.
...
>> the kernel-team. Currently building udebs from the linux-2.6 source
>> would add another indirection to the build process, not remove one.
>
> Another indirection ? It would mean that in a single upload, all kernel
> related .debs and .udebs are built. Furthermore, it allows to autobuild the
> kernel, which is not currently possible for the .udebs, which means 10+ times
> human intervention, uncoordinated uploads, uncoordinated NEW handling, random
> delays for each arch, and that the porters are left alone with random breakage
> introduced by untested changes of kernel-wedge, except for the pet arch of the
> d-i leaders.
The indirection is that every change in the module split needed by the
D-I team would have to through the kernel-team and would require a
full source upload with days of buildd time. Which is quite insane
just to move a module from package A to package B so the floppy image
doesn't overflow while things get worked out.
>> > Compare this to the current situation, favored by the installer team, probably
>> > just to oppose me, where every porter has to redo the module selection job by
>> > hand, where none of them are informed about the problems faced by the others,
>> > where a slight indisponibility of one of the porters result in thee brokeness
>> > of the related build, and accusations of lazyness by the d-i leaders, and you
>> > see how this would be dissatisfying, and how the d-i leaders in their
>> > pettiness see my technical proposals as an attack against their supremacy.
>>
>> The same can be said to happen for the kernel-team. Changing
>> responcibility to another team does not magicaly solve problems. I
>> somewhat feel that you just say all this (moving udebs into the
>> linux-2.6 source) because you were kicked out of D-I.
>
> No, the kernel team builds from a single package, for all arches, so there
> needs to be coordination between the maintainers/porters, we care about
Which in no way garanties that there is such coordination. The need
for coordination in the D-I team is just as great as in the kernel-team.
> other-people arches, and we never accused people of being lazy and other ugly
Well, YOU do and you are part of the kernel team.
> things. We managed to do 1-day uploads for all arches except m68k (because of
> the way upstream works there).
I would rather have 7-day uploads and have the kernel DFSG free and
distributable. Two things that it is not and known since before sarge
strictly speaking.
> Err, they break d-i compatibility every so often anyway, and having kernel modules
> without the corresponding kernel .debs is a GPL violation anyway.
No it isn't. The GPL only requires that you have the source and that
is available via the linux-tree package even for past versions no
longer in the archive.
>> And again, how do extra section help there? They have nothing to do
>> with that.
>
> They have all to do with it, in responding to the critic of exploding Package
> size with the number of flavours. But then amd64 and x86 have only one or
> relatively few flavours used in the installer anyway. Now, compare this to
> arm, mips or m68k, which are the arches who will benefit more from low-mem
> situations too.
>
>> >> 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.
>> >
>> > Maybe, please read what i have proposed here, and then tell me again there are
>> > no benefits.
>>
>> You started with proposing creating new sections.
>>
>> Since I showed that new sections have only drawbacks you now suddenly
>> propose building udebs in the linux-2.6 source.
>
> Suddenly, i have been saying exactly that since january or earlier, go read
> the archive, i was even going to implement it, when i was hit by a barrage of
> hatefullness and kicked out of d-i, and threatened by Frans if i ever dared
> work on it.
I'm talking about this thread.
>> So far two totaly unrelated features while you try to make it look
>> like the later supports the former.
>
> Because you fail to understand the whole picture, it seems such to you, please
> read the past discussions on the topic, and try to understand the proposal
> with an open mind.
You assume knowledge about past discussions. You should have included
a link to your proposal when you started mentioning features of it the
first time.
...
> Maybe, bvut do you really believe that what they did is right ? Would you
> really be able to work with such persons without feeling ashamed of yourself
> for having said nothing ? Or even like some encouraged them ?
The only thing I believe is that you acting wrong NOW and you keep
acting wrong NOW. I wasn't involved in your D-I incident and I refuse
to be drawn into it.
> As for perception, anyones perception of me is anyway hosed, and half of
> debian if not more has me in their killfill, and just wish i would go away and
> be silent, so what have i too lose ? That they kick me out ? Let it come to
You loose any chance of getting back in or anyone listening to you.
And just to let you know, from now on I will ignore all mails that
include the D-I incident or you being mistreated. If you can't keep
to the technical discussion then I'm sorry but I want to do some
productive work and not wallow in self pitty (be that justified or not
I simply don't care).
MfG
Goswin
Reply to: