Modern Update System

[Rudolf Kastl]

2005/11/29, n0dalus <n0dalus+redhat at gmail.com>:
> On 11/29/05, Benjy Grogan <benjy.grogan at 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.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

hopefully there will be patches for src rpms too then *rolls eyes*,
else i dont know how a regular hobby dev would be able to fix or
enhance stuff.

also take a look at: http://freshmeat.net/projects/rpmdc/. you can
just go ahead and start your delta mirror, no one is holding you back.

while it would be nice to save bandwidth on updates i think that the
potential backdraws are worse than the gain can ever be.

regards,
Rudolf Kastl

p.s. id be alot happier if people were able to really look up stuff on
the net first before kicking off major "must have, must be" or similar
ideas simply cause you are pushing people to do some work without
having done your own work on looking up the alternatives etc...