On Sat, 26 Mar 2005 11:54:10 -0600, Les Mikesell <lesmikesell@xxxxxxxxx> wrote:
>
> It looks like it may help with the 'multiple conflicting repository'
> issues, but there are some other problems with existing tools.
> Does it add any way to
> (a) make sure the repository is in a consistent state during
> the update, and
> (b) perform updates on production machines making sure that
> they get exactly the same packages that have been previously
> tested, regardless of subsequent additions to the repository?
>
> The yum maintainers have suggested keeping 2 local mirror copies
> of the entire repository to accomplish this (with associated
> config changes and manual package copying) but that seems like
> a horrible amount of overhead just to make a tool work predictably.
>
> Couldn't something like subversion be put under the covers to
> allow atomic commits of all dependent packages at once into
> the repository and allow upgrades (or downgrades) to tags or
> timestamps? This seems like a job that needs exactly the set
> of functions provided by a revision control package.
>
If you required the packages to be in a SVN/CVS repository, that's
quite an extra load on the server just to be a package mirror, so many
(all?) of the freelly donated mirrors would stop doing it for free. I
use a local repository and find it to be not only more reliable (I
control exactly what is in it) but also much easier to work with. I
can add my own packages and it is MUCH faster than even the fastest of
nearby mirrors.
I think that you ask for too much from the mirrors/distributions.
Having people add in code is something that you can get shared freely,
there is no large cost to sharing code. Adding in
repositories/mirrors that have lots of extra benefits like this which
require actual non-trivial costs (disk space, revision system
overhead) - then, in my mind, you are moving into the area of a paid
service.
Greg
