On 11/29/05, Benjy Grogan <benjy.grogan(a)gmail.com> wrote:
Yeah, that's what I'm starting to think. Having to have the
initial rpm on
your hard drive all the time would be another kind of waste.
It comes down to more fundamental changes. If the method of keeping rpms on
your hard drive is ditched then you're left with sending pure binary patches
to the actual files. That's the best way, but a complete reorganization is
then needed.
Sounds like one of these long projects that requires corporate funding to
see it through a few years work. I think it's an important enough challenge
to tackle that Red Hat, IBM and Novell should work together to do this.
It's alot of work any way it's done. Best to go for the best solution and
find some backing and then hope everyone interested shows up to help out.
Benjy,
AWWTF
I wonder if is possible to build a multipart rpm format, so by looking
at it's header you could determine you only need the first x bytes,
which would be the incremental binary patches between it and the last
couple of versions (depending on how much extra space you want to take
up). It might be possible to mark this first part so it will be
ignored by earlier versions of yum/rpm. Can someone with a good
understanding of the rpm format and how it is parsed comment on this
idea?
I am thinking something like this:
[|header|incremental_patch_1|incremental_patch_2|...|]|normal_rpm_data
Where the stuff in [] is (if possible) formatted so the current rpm
system ignores it.
Depending on what percentage of the filesize you want to take up with
binary patches, there will be anywhere from 0 patches (and no header
since it's not needed), to a patch between every previous version (if
they're only a couple of kb each, it shouldn't hurt).
The header would contain the offsets for all the patches, sha1 sums of
each piece, and version numbers so the reader could determine which
ones it needs. If missing one of the patches it would just proceed to
download the whole rpm and update normally.
Each patch should have hashes for each file that needs updating and if
any one of these don't match the files on the disk, it proceeds to
download the rest of the rpm and update normally.
I don't know if I agree that this needs corporate funding and years of
work. I think a system like this could be written in under a year by
volunteers.
n0dalus.