Re: 2.6.12 is in testing
On Wed, Sep 14, 2005 at 12:09:31PM -0400, Joey Hess wrote:
> Sven Luther wrote:
> > Mmm, why is this tripple need of holding udeb state necessary ?
>
> Well, look at the code to main-menu, anna, and udpkg..
Hehe, will do in Oldenbourg.
> > Would not solving this go a great way for diminishing general memory
> > usage anyway ?
>
> No, this is not the current high water mark for memory usage in d-i.
> That point is currently reached after anna has loaded all the udebs and
> partman is running, just before swap space is set up. Decreasing the
> memory used at other points is fairly useless, unless they mushroom all
> out of control as splitting the module udebs might do.
Ok.
> OTOH, splitting the module udebs does indeed have the potential to
> decrease memory usage at that high water mark. If someone did some work
> and some tests and got some real numbers that would be fine. I'm a bit
> tired of the constant empty proposals to do it though.
Bah, we will see in two weeks, but see below.
BTW, the other proposal was to not packages kernels or .udebs as modules, but
i don't know upto what point the d-i infrastructure is upto it.
We already have the dependency information thanks to depmod, and could use
this, and have all the modules unpacked on the server somewhere. Need to see
how we handle the versioning issues though.
> > Nope, with the common kernel package we did take great care to *NOT* need
> > individual maintainers to do the upload, and to not need each porter to make
> > uploads, and thus we heavily dislike you putting the burden on us like that
> > again
>
> Someone has to do the work for d-i to support architectures if it will
> continue to support them. This work is currently largely not being done,
> and as a result it seems very likely that d-i won't be able to release
> with support for quite a lot of architectures.
This is indeed the case, but i think it is sign of a generic disafection of
d-i coding post sarge release.
> I observe that the many of the people who _are_ doing the work to keep
> d-i working for an architecture are also involved in keeping the kernel
> working for that architecture, which is IMHO nowhere near as trivial as
> you make it out to be.
Nope, but i don't think there is a real problem in making d-i kernel .udebs
working for d-i, if said kernels already worked outside of d-i.
And of all the powerpc issues i had with current d-i, i think none where
kernel related, but generic code stale because i was the only powerpc guy left
to work on d-i. I think powerpc is now in pretty good shape, apart from
oldworld, which will be fixed in oldenbourg i hope, and apus/nubus.
> > Exactly that is the problem, they lag because there is a human factor involved
> > for something which is pretty automated.
>
> It's either trivial or reasonably hard, depending on what changes have
> happened in the kernel.
It is trivial if there was no api change, and failry automatable in the other
case too, The only reason you had problems with it is because you lacked the
infrastructure to do it nicely, and the fact that the artificial grouping of
kernel modules in package may make floppy media outgrow their size.
> > I still think my proposal makes more sense in the long run, but let's discuss
> > this more in oldenbourg.
>
> I don't know what the point is in discussing it over and over if noone
> is doing the work.
Did i not say i intent to work on this in oldenbourg ? Come on it is in two
weeks, and i have other things to do right now, what else do you want ?
Also, notice that if we get a "no, it is not a good idea" from you, there is
really no interest in coding anything, especially on my part and the "you
delayed singlehandedly the sarge release by a whole week" trashing i got from
you last time i did some modifications of this ilk.
Friendly,
Sven Luther
Reply to: