On 8 Jan 2001, Goswin Brederlow wrote:
> Then that feature should be limited to non-recursive listings or
> turned off. Or .listing files should be created that are just served.
*couf* rproxy *couf*
> So when you have more blocks, the hash will fill up. So you have more
> hits on the first leve
> " " == Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> On 8 Jan 2001, Goswin Brederlow wrote:
>> I don't need to get a filelisting, apt-get tells me the
>> name. :)
> You have missed the point, the presence of the ability to do
> file listings prevents the adoption of
On 8 Jan 2001, Goswin Brederlow wrote:
> > Apparently reversing the direction of rsync infringes on a
> > patent.
> When I rsync a file, rsync starts ssh to connect to the remote host
> and starts rsync there in the reverse mode.
Not really, you have to use quite a different set of o
> " " == Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> On 7 Jan 2001, Goswin Brederlow wrote:
>> Actually the load should drop, providing the following feature
>> add ons:
>>
>> 1. cached checksums and pulling instead of pushing 2. client
>> side unpackging of compre
> "Goswin" == Goswin Brederlow <[EMAIL PROTECTED]> writes:
Goswin> URL?
http://linuxcare.com.au/projects/rproxy/>
The documentation seems very comprehensive, but I am not sure when it
was last updated.
Goswin> Sounds more like encapsulation of an rsync similar
Goswin> protocol i
> " " == Brian May <[EMAIL PROTECTED]> writes:
> "Goswin" == Goswin Brederlow <[EMAIL PROTECTED]> writes:
Goswin> Actually the load should drop, providing the following
Goswin> feature add ons:
> How does rproxy cope? Does it require a high load on the
> server? I suspe
> "Goswin" == Goswin Brederlow <[EMAIL PROTECTED]> writes:
Goswin> Actually the load should drop, providing the following
Goswin> feature add ons:
How does rproxy cope? Does it require a high load on the server? I
suspect not, but need to check on this.
I think of rsync as just bein
On 7 Jan 2001, Goswin Brederlow wrote:
> Actually the load should drop, providing the following feature add
> ons:
>
> 1. cached checksums and pulling instead of pushing
> 2. client side unpackging of compressed streams
Apparently reversing the direction of rsync infringes on a patent.
Plus th
> " " == Matt Zimmerman <[EMAIL PROTECTED]> writes:
> On Sun, Jan 07, 2001 at 03:49:43PM +0100, Goswin Brederlow
> wrote:
>> Actually the load should drop, providing the following feature
>> add ons: [...]
> The load should drop from that induced by the current rsync
On Sun, Jan 07, 2001 at 03:49:43PM +0100, Goswin Brederlow wrote:
> Actually the load should drop, providing the following feature add
> ons:
> [...]
The load should drop from that induced by the current rsync setup (for the
mirrors), but if many, many more client start using rsync (instead of
FT
Sam Vilain <[EMAIL PROTECTED]> writes:
> On Fri, 5 Jan 2001 19:08:38 +0200
> [EMAIL PROTECTED] (Sami Haahtinen) wrote:
>
> > Or, can rsync sync binary files?
> > hmm.. this sounds like something worth implementing..
>
> rsync can, but the problem is with a compressed stream if you insert
> or al
> " " == Sam Vilain <[EMAIL PROTECTED]> writes:
> On Fri, 5 Jan 2001 09:33:05 -0700 (MST) Jason Gunthorpe
> <[EMAIL PROTECTED]> wrote:
>> > If that suits your needs, feel free to write a bugreport on
>> apt about this. Yes, I enjoy closing such bug reports with a
>> ter
On Fri, 5 Jan 2001 19:08:38 +0200
[EMAIL PROTECTED] (Sami Haahtinen) wrote:
> Or, can rsync sync binary files?
> hmm.. this sounds like something worth implementing..
rsync can, but the problem is with a compressed stream if you insert or alter
data early on in the stream, the data after that ch
On Fri, 5 Jan 2001 09:33:05 -0700 (MST)
Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
> > If that suits your needs, feel free to write a bugreport on apt about
> > this.
> Yes, I enjoy closing such bug reports with a terse response.
> Hint: Read the bug page for APT to discover why!
>From bug report
On Sun, Jan 07, 2001 at 12:53:14PM +1100, Drake Diedrich wrote:
> On Sun, Jan 07, 2001 at 11:43:39AM +1100, Sam Couter wrote:
> >
> > A deb plugin would be better. :)
>
>One problem with a deb plugin is that .debs are signed in compressed
> form. gzip isn't guaranteed to produce the same co
On Sun, Jan 07, 2001 at 11:43:39AM +1100, Sam Couter wrote:
>
> A deb plugin would be better. :)
One problem with a deb plugin is that .debs are signed in compressed
form. gzip isn't guaranteed to produce the same compressed file from
identical uncompressed files on different architectures an
> "Sam" == Sam Couter <[EMAIL PROTECTED]> writes:
Sam> Andrew Stribblehill <[EMAIL PROTECTED]> wrote:
>> Doesn't gzip have a --rsync option, or somesuch? Apparently
>> Andrew Tridgell (Samba, Rsync) has a patch to do this, but I
>> don't know whether he passed it onto the gzip
Andrew Stribblehill <[EMAIL PROTECTED]> wrote:
>
> Doesn't gzip have a --rsync option, or somesuch? Apparently Andrew
> Tridgell (Samba, Rsync) has a patch to do this, but I don't know
> whether he passed it onto the gzip maintainers.
I like the idea of having plugins for rsync to handle differen
Quoting Goswin Brederlow <[EMAIL PROTECTED]>:
> > " " == Sami Haahtinen <[EMAIL PROTECTED]> writes:
>
> > Or, can rsync sync binary files?
>
> Of cause, but forget it with compressed data.
Doesn't gzip have a --rsync option, or somesuch? Apparently Andrew
Tridgell (Samba, Rsync) has a pa
Jason Gunthorpe wrote:
>
> Hint: Read the bug page for APT to discover why!
>
Looking through the apt bugs., saw this one, rejected:
Bug#77054: wish: show current->upgraded versions on upgrade -u
My private solution to this is the following patch to `apt-get':
--- algo
> " " == Junichi Uekawa <[EMAIL PROTECTED]> writes:
> In 05 Jan 2001 19:51:08 +0100 Goswin Brederlow
> <[EMAIL PROTECTED]> cum veritate
> scripsit : Hello,
>> I'm currently discussing some changes to the rsync client with
>> some people from the rsync ML which would unc
In 05 Jan 2001 19:51:08 +0100 Goswin Brederlow <[EMAIL PROTECTED]> cum veritate
scripsit :
Hello,
> I'm currently discussing some changes to the rsync client with some
> people from the rsync ML which would uncompress compressed data on the
> client side (no changes to the server) and rsync thos
> " " == Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> On 5 Jan 2001, Goswin Brederlow wrote:
>> If that suits your needs, feel free to write a bugreport on apt
>> about this.
> Yes, I enjoy closing such bug reports with a terse response.
> Hint: Read the bug page for
> " " == Sami Haahtinen <[EMAIL PROTECTED]> writes:
> On Fri, Jan 05, 2001 at 03:05:03AM +0100, Goswin Brederlow
> wrote:
>> Whats the problem with a big Packages file?
>>
>> If you don't want to download it again and again just because
>> of small changes I have a b
Previously Sami Haahtinen wrote:
> this would bring us to, apt renaming the old deb (if there is one) to the
> name of the new package and rsync those. and we would save some time once
> again...
There is a --fuzzy-names patch for rsync that makes rsync do that itself.
> Or, can rsync sync binar
On Fri, Jan 05, 2001 at 05:46:35AM +0800, zhaoway wrote:
> > how about diffs bethween dinstall runs?..
>
> sorry, but i don't understand here. dinstall is a server side thing here?
yes, when dinstall runs it would copy the old packages file to, lets say,
packages.old and create it's changes to th
On Fri, Jan 05, 2001 at 03:05:03AM +0100, Goswin Brederlow wrote:
> Whats the problem with a big Packages file?
>
> If you don't want to download it again and again just because of small
> changes I have a better solution for you:
>
> rsync
>
> apt-get update could rsync all Packages files (yes,
On 5 Jan 2001, Goswin Brederlow wrote:
> If that suits your needs, feel free to write a bugreport on apt about
> this.
Yes, I enjoy closing such bug reports with a terse response.
Hint: Read the bug page for APT to discover why!
Jason
If you don't like large Packages files, implement a rsync transfer
method for them.
--
see shy jo
> " " == zhaoway <[EMAIL PROTECTED]> writes:
> hi, [i'm not sure if this has been resolved, lart me if you
> like.]
> my proposal to resolve big Packages.gz is through package pool
> system.
Whats the problem with a big Packages file?
If you don't want to download it a
final thoughts ;-)
On bigger and bigger Packages.gz file, a try
The directory structure looks roughly like this:
debian/dists/woody/main/binary-all/Packages.deb
debian/pool/main/a/abba/abba_1989.orig.tar.gz
abba_1989-12.diff.gz
abba_1989-12.dsc
On Thu, Jan 04, 2001 at 11:19:25PM +0100, Petr Cech wrote:
> On Fri, Jan 05, 2001 at 06:07:20AM +0800 , zhaoway wrote:
> > then, apt-get update will do nothing,
> > apt-get install some.deb will first download some.pkg-gz, then check its
> > dependency,
> > then grab them.pkg-gz all, then install.
[quote myself, ;-) this is semi-final now ;-)]
another solution is to let every single deb provides its.pkg-gz
then, apt-get update will do nothing,
apt-get install some.deb will first download some.pkg-gz, then check its
dependency,
then grab them.pkg-gz all, then install.
that is a minimum.
On Fri, Jan 05, 2001 at 06:07:20AM +0800 , zhaoway wrote:
> On Thu, Jan 04, 2001 at 11:19:59PM +0200, Sami Haahtinen wrote:
> > how would the package manager (namely apt) know which ones you need.. even
> > if
> > you don't have X11 installed (and apt assumes you don't need X11 packages
> > file)
On Fri, Jan 05, 2001 at 06:07:20AM +0800, zhaoway wrote:
> another solution is to let every single deb provides its.pkg-gz
>
> then, apt-get update will do nothing,
> apt-get install some.deb will first download some.pkg-gz, then check its
> dependency,
> then grab them.pkg-gz all, then install.
On Thu, Jan 04, 2001 at 11:19:59PM +0200, Sami Haahtinen wrote:
> how would the package manager (namely apt) know which ones you need.. even if
> you don't have X11 installed (and apt assumes you don't need X11 packages
> file)
> doesn't mean that you wouldn't want to install x11 packages file.
a
On Thu, Jan 04, 2001 at 11:01:15PM +0200, Sami Haahtinen wrote:
> On Fri, Jan 05, 2001 at 03:02:15AM +0800, zhaoway wrote:
> > my proposal to resolve big Packages.gz is through package
> > pool system.
> >
> > add 36 or so new debian package, namely,
> >
> > [a-zA-Z0-1]-packages-gz_date_all.deb
>
On Thu, Jan 04, 2001 at 03:07:00PM -0600, Vince Mulhollon wrote:
>
> The only other possibility not yet proposed (?) would be to split the
> packages file by section.
>
> base-packages
> games-packages
> x11-packages
> net-packages
>
> Then a server that just doesn't do x11 or doesn't go games h
Fax to:
Subject: Re: package pool and big
Packages.gz file
01/04/2001
On Fri, Jan 05, 2001 at 03:02:15AM +0800, zhaoway wrote:
> my proposal to resolve big Packages.gz is through package
> pool system.
>
> add 36 or so new debian package, namely,
>
> [a-zA-Z0-1]-packages-gz_date_all.deb
>
> contents of each is quite obvious. ;-)
> and a virtual unstable-packages-g
On Fri, Jan 05, 2001 at 03:17:30AM +0800, zhaoway wrote:
> [read my previous semi-proposal]
>
> this has some more benefits,
>
> 1) package maintainer could upload (to pool) in whatever
> frequency they like.
in an ideal world, developer should upload to ''xxx-auto-builder'' ;-)
9i'm turning ou
[read my previous semi-proposal]
this has some more benefits,
1) package maintainer could upload (to pool) in whatever
frequency they like.
2) release is seperated from package pool which is a storage
system. and release is a qa system.
3) release could be managed through BTS on specific packag
hi,
[i'm not sure if this has been resolved, lart me if you like.]
my proposal to resolve big Packages.gz is through package
pool system.
add 36 or so new debian package, namely,
[a-zA-Z0-1]-packages-gz_date_all.deb
contents of each is quite obvious. ;-)
and a virtual unstable-packages-gz depe
43 matches
Mail list logo
