Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Sat, Aug 12, 2006 at 03:13:13PM +0200, Goswin von Brederlow wrote:
> CC limited to debian-kernel as this isn't for release anymore.
> Sven Luther <firstname.lastname@example.org> 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.
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.
> 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.
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
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
> 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.
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.
> 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
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.
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.
> > 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.
> 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
> > 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
> > 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 ?
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 ...