|From:||"Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx>|
|Date:||Sun, 16 Dec 2007 14:39:26 +0100|
Matthias Schmidt wrote: >> I wonder, why bother with binary patches? Network is cheap nowadays, so >> we could as well distribute complete binaries. > Thats right, but I'm a fan of saving disk space and bandwith. Distributing > complete binaries has one big advantage. We could update user-modified > binary files which is not easily possible with diff/pach. Yes. Both ways don't necessarily exclude each other, assuming that mirrors have enough space (they do, usually). >>> I think most >>> server admins also stick with the GENERIC kernel (at least I do it), so >>> support for GENERIC would IMO be enough. >> As soon as you compile stuff, you probably will get different binaries. >> If you update the kernel, you need to update the userland as well. > Yep, that's what the problem is about. A combined source/binary approach then could realize that there is a need to recompile the kernel and do so, in case the config was changed. If not, a replacement kernel can be installed. Same for userland binaries. >> If we had a way to identify from which sources a binary was compiled >> from, we could do upgrades more easily. Maybe enhance gcc to include a >> checksum of the sources into the object? > Do you mean with or without patching? That would be without patching. A way to find out which sources a particular binary corresponds to, and if these sources are the same like the ones being upgraded, you can replace the (different) binary with a fixed replacement. >> In any case, when doing a binary upgrade, we should at the same update >> the sources, if installed. > > Why? Most admins don't even have sources installed. If someone wants > only a (security) fix I think its sufficent to update only the relevant > files. Yes, I meant: If there are sources, these should be updated at the same time, so that source compiles will contain the fix as well.
Description: OpenPGP digital signature