Re: Modern Update System

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/29/05, Benjy Grogan <benjy.grogan@xxxxxxxxx> 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.

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux