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.. > 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. 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. > 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. 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. > 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. > 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. -- see shy jo
signature.asc
Description: Digital signature
