Re: Proposal: A new approach to differential debs

On Wed, Aug 16, 2017 at 01:38:11AM +0200, Julian Andres Klode wrote: > bsdiff was specifically invented for patching binaries. See the > evaluation I posted a (few) hour(s) ago. It's used succesfully by > FreeBSD, Chrome, Android, Apple App Store, and other places. [...] > Especially for security

Re: A radically different proposal for differential updates

Hi! While this sounds indeed interesting, I think it's impractical for at least the two reason below: On Tue, 2017-08-15 at 09:26:24 +0200, Christian Seiler wrote: > AFAQ (Anticipated frequently asked questions): > > Q: How can you reconstruct a tarball from the installed system? Won't >

Re: Proposal: A new approach to differential debs

Hi, Julian Andres Klode wrote: > Today's research has shown that rolling hashes do not perform well > on executables because of changing offsets and so on destroying the > hashes. There were no measurable space savings when adding fairly > similar firefox releases to either a casync or borg

Re: A radically different proposal for differential updates

Isn't there kind of a universal issue that tar and compression happen sort of in the wrong order? Wouldn't it make more sense to make files that were .gz.tar (ie. compress the files individually, then have an index into them via tar.) Then tar works perfectly well for extracting individual files

Re: Proposal: A new approach to differential debs

On Sun, Aug 13, 2017 at 12:38:56PM +0300, Adrian Bunk wrote: > On Sat, Aug 12, 2017 at 02:16:21PM -0400, Julian Andres Klode wrote: > >... > > I think delta debs are generally a thing we should aim to have, > >... > > It sounds like something that would have been a cool feature 20 years > ago

Re: Proposal: A new approach to differential debs

On Sun, Aug 13, 2017 at 10:53:16AM -0400, Peter Silva wrote: > You are assuming the savings are substantial. That's not clear. When > files are compressed, if you then start doing binary diffs, well it > isn't clear that they will consistently be much smaller than plain new > files. it also

Evaluation (Re: Proposal: A new approach to differential debs)

On Sat, Aug 12, 2017 at 02:16:21PM -0400, Julian Andres Klode wrote: > Hi everyone, > > (I CCed -devel and deity, but we probably should just discuss > that on -dpkg) > > while breakfast here at DebConf, the topic of delta upgrades > came up. I think delta debs are generally a thing we should >

Re: A radically different proposal for differential updates

On Tue, Aug 15, 2017 at 09:26:24AM +0200, Christian Seiler wrote: > Hi there, > > I've come to believe that binary diff packages are not the best way of > solving this issue. Intead I'd like to propse a radically different > solution to this issue. > > The gist of it: instead of adding a format

Re: Upstream Tarball Signature Files

Hi, On Mon, Aug 14, 2017 at 10:13:10AM -0700, Russ Allbery wrote: > Henrique de Moraes Holschuh writes: > > > We do when the binary sig is small enough to be stored along with the > > inode, instead of requiring an entire filesystem block (4KiB), and the > > armored signature

Re: All your package subscriptions have been cancelled

Hi! On Thu, 2017-08-10 at 13:02:29 +0200, Raphael Hertzog wrote: > On Fri, 04 Aug 2017, Guillem Jover wrote: > > On Fri, 2017-08-04 at 02:19:59 -, ow...@tracker.debian.org wrote: > > > The email debian-dpkg@lists.debian.org bounces too much, it has been > > > unsubscribed from the > > >

Processed: Re: Bug#872223: tex-common: fails to configure, fmtutils reports errors about missing files

Processing control commands: > reassign -1 texlive-htmlxml Bug #872223 [dpkg] tex-common: fails to configure, fmtutils reports errors about missing files Bug reassigned from package 'dpkg' to 'texlive-htmlxml'. Ignoring request to alter found versions of bug #872223 to the same values

A radically different proposal for differential updates

Hi there, I've come to believe that binary diff packages are not the best way of solving this issue. Intead I'd like to propse a radically different solution to this issue. The gist of it: instead of adding a format for how deltas work, I propose to introduce a new format for storing Debian