#include
* curt manucredo (hansycm) [Fri, May 26 2006, 07:53:58PM]:
> this can lead to this:
> --
> if a patch is available:
>
> 1. look in /var/cache/apt/packages for the package to be updated. if the
> old one is there patch it's files. md5sum. happy? if not...
>
> 2. try
A Mennucc <[EMAIL PROTECTED]> wrote:
> Absolutely true. Look at this
>
> $ ls -s tetex-doc_3.0-17_all.deb tetex-doc_3.0-18_all.deb
> 42388 tetex-doc_3.0-18_all.deb 42340 tetex-doc_3.0-17_all.deb
>
> $ bsdiff tetex-doc_3.0-17_all.deb tetex-doc_3.0-18_all.deb brutal.bsdiff
> $ ls -s brutal.bsdiff
>
hi
by quite a coincidence, while you people were discussing this idea, I was
already implementing it, in a package called 'debdelta' : see
http://lists.debian.org/debian-devel/2006/05/msg03120.html
Moreover, by some telepathy :-) , I already included features you were
proposing, and addressed
"curt manucredo (hansycm)" <[EMAIL PROTECTED]> writes:
> Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> wrote:
>
> >Nope. You will need to keep all normal debs anyway, for new
> >installations.
>
> i thought it could be possible in the end to download the tree-package
> and all its patches to then h
Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> wrote:
>Anyway, this was proposed some times now. Have you actually read the >old
>threads and can explain why your proposal is better and actually works?
>Why haven't you implemented it yet?
not right now. i just have found out that there were some sam
Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> wrote:
>Nope. You will need to keep all normal debs anyway, for new
>installations.
i thought it could be possible in the end to download the tree-package
and all its patches to then have the latest package for a new install!
so i thought there will b
Tyler MacDonald <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>> That is quite unacceptable. We have debs in debian up to 160Mb
>> (packed) and 580Mb unpacked. That would require 2.7 Gb and nearly 10Gb
>> ram respectively.
>>
>> Seems to be quite useless for patchi
"curt manucredo (hansycm)" <[EMAIL PROTECTED]> writes:
> II.B. on the upload and storage side
>
>
> the upload process may need some more changes though (e.g.: for
> automation). if this ever comes true, there will have to be a period of
> time where both, the
Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> That is quite unacceptable. We have debs in debian up to 160Mb
> (packed) and 580Mb unpacked. That would require 2.7 Gb and nearly 10Gb
> ram respectively.
>
> Seems to be quite useless for patching full debs. One would have to
> limit it to a file
Tyler MacDonald <[EMAIL PROTECTED]> writes:
> +1. We've been using bsdiff (http://www.daemonology.net/bsdiff/) at
> work for some internal stuff and it's great.
Oh, and one more thing:
| bsdiff is quite memory-hungry. It requires max(17*n,9*n+m)+O(1)
| bytes of memory, where n is the size
Tyler MacDonald <[EMAIL PROTECTED]> writes:
> http://www.daemonology.net/bsdiff/
How does that compare with rsync batch files?
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> I. the reason why i suggest a patch-oriented download process
+1. We've been using bsdiff (http://www.daemonology.net/bsdiff/) at
work for some internal stuff and it's great. Furthermore, since unstable has
gone to using diffs for the Packages files, my dselect updates have been
*way* fa
Dear Debian-Developers All Over The World!
may i introduce my,
proposal for a more efficient download process
I. the reason why i suggest a patch-oriented download process
II. a brief description
II.A. on the
13 matches
Mail list logo
