On Sat, Aug 12, 2006 at 07:46:16PM +0200, Goswin von Brederlow wrote:
> Sven Luther <[EMAIL PROTECTED]> 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.
Also, do you really need a gazillion of not-for-your-hardware modules
installed ?
> 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.
> 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
Indeed, this was the main critic against the finer grained module proposal
(apart from all the hateful stuff they said to me at the same time naturally).
> bigger reason would be flooding NEW with so many tiny udebs on an ABI
> change and thus driving ftp-master nuts.
Nope, because they would all be part of the same source package, and i think
they can easily enough authorize all binaries of a single source package.
>
> > 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.
"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.
Notice also that the apus flavour was killed from d-i once they kicked me out,
because it was too much work for them to fix it.
> >> 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
Yeah, but they do it for x86, amd64 and some of their pet architectures.
> 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.
> > 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
other-people arches, and we never accused people of being lazy and other ugly
things. We managed to do 1-day uploads for all arches except m68k (because of
the way upstream works there).
Compare that to the sarge kernel situation. This is exactly the state the d-i
folk have stayed in, incapable of seeing the greater good, the post-release
security needs. And the worse is that they put Frans as leadership, who apart
from being so haughty he believes he knows the kernel better than the kernel
team, is also incapable of accepting novel ideas not coming from him (or
somehow feels diminished by the lest critic, but hasn't any shame in criticing
others).
> >> 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.
Sure it is going to happen. Wheter debian will be able to take benefit of it
or not is another question.
> > 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.
Maybe,
> >> > 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.
Err, they break d-i compatibility every so often anyway, and having kernel
modules
without the corresponding kernel .debs is a GPL violation anyway.
> 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.
> 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.
>
> >> > 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 ? I got kicked because i dared suggest that everythign is not best, and
started to make proposals on how to change it, which displeased frans, as he
thus felt chalenged in his leadership role, and felt the need to punish me for
it.
> >> ...
> >> > 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.
Maybe, but i have never pofited of death and illness to get vengeance, while
frans did, while i begged him explicitly not to do so in a private mail.
> > 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
nope, but you like all others locked the other way while frans and a few other
d-i team members stabbed me in the back, and then complained when i dared
mention it.
> 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?
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 ?
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
that, and i am very interested in the public discussion that will follow such
a proposal, and the perception it will bring to debian. 8 years of my time i
gave to debian, with all my heart and passion, but it will never be the same,
thanks to a bunch of people who believe that nothing is more important than
their own opinion of themselves.
Hurt,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
