Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
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
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.
I also see how more sections would change any of this? Has someone
said we can't do finer grained kernel module udebs because the
Packages file will grow to big with all those udebs? I think a far
bigger reason would be flooding NEW with so many tiny udebs on an ABI
change and thus driving ftp-master nuts.
> Furthermore, with a set of smart tools, some Makefile/Kconfig analysis, and a
> bit of graph theory, it would allow to automate the module .udeb creation,
> based only on the choice of .config options, and thus make the job of the
> porters so much easier, needing only to consider the config options one single
> time, to see if they need to be enabled, and then decide if this particular
> option is one which would enable a module which would be needed for the
> installer.
>
> All the rest, the description, the depednecy graph, etc, will be taken from
> the kernel source directly (with a few overrides for dependencies for some
> modules who do not (yet maybe) carry the dependency information in their
> source code.
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.
>> 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
>
> Well, apart from the installer pulling some 2.4.27-apus .udebs in on a
> 2.6.12-powerpc flavour, which is indeed a mistake which would be solved by
> this solution, this is hardly the point.
>
> The main point here, is that it is easily doable to automate a set of tasks,
> and to keep only the small minimum set of human decision in a single place,
> and thus spare everyone a lot of work, which is after all what computers where
> invented for in the first place.
No automation exists so for now someone has to do it manualy and that
someone is the D-I team currently as they know what D-I needs. And not
the kernel-team. Currently building udebs from the linux-2.6 source
would add another indirection to the build process, not remove one.
> 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.
>> 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.
>
> Indeed. But then, there is probably another set of modifications that could be
> done to help this go around. The kernel team has already stated that they are
> not really happy in the way of how NEW is handled in relation of kernels.
So even more magic that nobody has or wants to write or even will
allow. The NEW queue will not be automated. IT IS NOT GOING TO
HAPPEN. Live with it.
> Another solution to the non-free DFSG mess and this would be to take the
> kernel fully out of debian, and have our own infrastructure to handle it as we
> see fit. This would solve the problem of those people in debian who like to do
> unneeded work, and impose unduly delays to other teams.
Feel free to make your own Debian.
>> > 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
>
> an abi bump imposes a rebuild of the d-i kernel .udebs, which means 10
> non-concertated uploads by people who are not well informed of the stuff, and
> 10 additional chances of delay, and 10 additional chances for a port to lag
> behind if the one porter for some reason is unavailable, as it wouldn't even
> come to mind of the d-i lmeaders to step in and help out, but instead chose to
> bash and accuse the porters of lazyness, as if they where some slaves to be
> whiped if they didn't work enough.
It also means that the exiting udebs compatible with the existing D-I
images remain available and can be updated on a case by case basis by
informed porters. Two sides of a coin.
And again, how do extra section help there? They have nothing to do
with that.
>> 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.
So far two totaly unrelated features while you try to make it look
like the later supports the former.
>> > 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.
>
> Why ? I am still kicked out of the d-i team, frans and co did not show the
> least hint of regret about this, and almost nobody dared critic them because
> of this.
Because the topic is not "Sven got kicked out of D-I". period.
>> ...
>> > 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.
>
> I don't care, if you had meet a people in real life who had behaved like frans
> did against me, chances are very good you would not want to have anything to
> do with him anymore, but within debian it is fully acceptable, and the one
> hurt is the one to take all blame ?
If I would meet people like you in real life I would just tune them
out after 5 minutes because they just repeat themself all the
time. Any bright ideas that get inserted inbetween the wining is then
just lost. And that is what is hapening to you.
> Look yourself in a mirror, think about it a bit, and then come back saying
> those things to me.
>
> It is true that it inconvenience you, and thus that you don't want to hear it
> and be able to ignore it, but closing your eyes on such behaviour is abject.
> And then, we kicked jonathan out of of debian, and got andrew to give up,
> while they didn't really go as far as Frans and the d-i team did go here.
>
> Hypocrits all of you ...
Hypocrite \Hyp"o*crite\, n. [F., fr. L. hypocrita, Gr. ? one who
plays a part on the stage, a dissembler, feigner. See
{Hypocrisy}.]
One who plays a part; especially, one who, for the purpose of
winning approbation of favor, puts on a fair outside seeming;
one who feigns to be other and better than he is; a false
pretender to virtue or piety; one who simulates virtue or
piety.
I didn't tell you I'm your friend and then stab you in the back. I
didn't tell you to open up your heart and tell me all your problems
and then complain about it. I clearly told you straight to your face
that I don't want to hear it. You can't get any more non-hypocrite
than that.
But here you are attacking me.
Well, do I want a person that attacks me for no reason to be part of
an essentail Debian team? No, lets not. Good that they have kicked him
out.
See how perception works?
> Hurt,
>
> Sven Luther
MfG
Goswin
Reply to: