Re: What I really like is the way FreeBSD has laid out there port making system.
On 25-Nov-1998, Gossamer <gossamer@tertius.net.au> wrote:
> Hamish Moffatt (hamish@debian.org) wrote...
>
> (Hey, I know you :))
Hey, I know both of you!
>
> > On Tue, Nov 24, 1998 at 11:55:24PM -0500, Edward Ing wrote:
> >> It didn't work of course. But anybody got and idea about how much
> >> work it would take to get whole ports structure paralleled for
> >> Debian or Redhat? All the code is open, I believe.
> > There's not really much need, as I see it. A FreeBSD port consists
> > off some control info and a patch; the makefile grabs the source
> > off the net, applies the patch, and compiles and installs the software.
> > Debian source packages also consist of the upstream source and a patch.
> > However, we provide precompiled binaries for all the packages where
> > FreeBSD do not.
>
> It would be -very- nice if you provided sorta "patch"es though - since
> we have binaries I guess a "patch" would consist of all the files
> in a particular .deb that have changed since the last release. I
> suspect this would be a fair bit less that all the files in a lot of
> casess.
xdelta can create binary patches and it does a better job than just
keeping changed files -- it will describe partial changes to a file too.
This would be really nice for packages that only change a little bit
with each revision but are very large.
The problem with this approach is mostly configuration (e.g. setting up
the scripts to create such patches, and further scripts to download and
apply them).
The way to do it is (at the ftp site end):
- Provide patches from each revision to the next revision.
- Maintain the invariant that the sum of the size of all the
patches is less than the size of the latest revision of the
package (there's no point downloading 5 patches to go from
1.0-1 to 1.0-5 is it is cheaper to just download 1.0-5
outright. If there is no point downloading them, there's
no point providing them for download). So when you create a
new patch, delete the oldest patches until this invariant holds.
- You can just transfer patches from mirror to mirror, and
the mirror can use the patch to upgrade the package from
one version to the next.
Then the client (dselect/apt) end just has to download the patches
necessary to go from current rev to latest rev, or if the patches
are not available, just download the package. This is assuming the
client has the previous version somewhere nearby, and it *knows* that
the previous version is *nearby* (e.g. cheap/quick to transfer) while the
patch is slow/expensive.
Note that what the clients do and what mirrors do is really pretty
similar, it's just the client does it on demand, one package at a time,
while the mirror does it for all packages.
The problem is that on average this will double the size of the ftp
archive. But it will reduce traffic. Except people will probably just
upgrade more often (the same way that building freeways increases
traffic).
--
Because I dislike being quoted I lie almost constantly when talking
about my work.
-- Terry Gilliam
Tyson Dowd <tyson@tyse.net> http://tyse.net/
Reply to: