[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: rsync and rawhide



Le dim 19/10/2003 à 14:26, Trae McCombs a écrit :

> (putting this at the bottom like a good little boy...)
> 
> I know I'm not the most technically inclined person, and I know I've not
> fully followed this thread.  However, I do feel in the case of saving
> bandwidth, and making upgrades more accessible to those that are limited
> with their pipes, I think it makes sense to have a low-file-sized
> solution for those wishing to upgrade their full systems.

[...]

Sure. Everyone here recognises saving bandwidth is good. What a lot of
people said is you don't have to compromise the standalone-package
system to get it. Most people who have been working with "patch" systems
just know they are a hell to manage.

There are many ways to save on bandwidth without going the patch route
(I'll talk one-computer setups here - people with big/medium/small
networks will probably be better of with a private rsynced mirror of the
iso area)

- only download the packages that need updating. This has been possible
for years now with apt/yum and before with solutions like autorpm. You
should realise most people only use one DE (with bits of the other),
office stuff or server stuff, etc Just using apt/yum this will probably
save you between one and 1.5 "isos" now. You won't get the special
update routines one can slip into a full-distro just-for-this-release
updater, but really all the special one-off stuff should be merged into
the packages themselves. It's a testimony to RH's overall quality that
has been mostly working for a long time. And I'm firmly convinced Fedora
will require more people doing Rawhide syncs, ie you'd better get this
working all the times because one can not roll out a new updater for
each rawhide update.

- perform rsync-like operations so the diffing between packages is
handled automagically and you still get full packages after the download
(ie have a mirror area of all installed packages, and let the download
manager reconstitue new packages with bits of the old ones). With modern
disks sizes maintaining this mirror area is nothing, and anyway it can
help a lot if part of the fs is destroyed (ie have something do a rpm
-Va and reinstall all damaged stuff). The main problem with vanilla
rsync is packages filenames change, and the packages themselves can be
reorganised (split/merged/renamed whatever). But if apt/yum can know
what package replaces another, it should certainly be possible to write
a specialized rsync that knows it too.

The main point of all this is any patches system puts the burden of
reassembling on the user (and packager, if the Suse system is what I
think it is they have to manually roll patch rpms in addition to regular
packages), just like traditional click-to-download systems put the
burden of dependency checking on the user. I don't want to spend a
minute of my precious time doing patch management - it should be handled
transparently and automatically, ie the user gets the same results as if
he'd done a full download without having to bother minding the tricks
the system used to save ressources.

Regards,

-- 
Nicolas Mailhot

Attachment: signature.asc
Description: Ceci est une partie de message=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]