[CentOS] Re: Why is yum not liked by some? -- CVS analogy (and why you're not getting it)

[Scot L. Harris]

On Sat, 2005-09-10 at 13:46, Les Mikesell wrote:
> On Sat, 2005-09-10 at 11:23, Scot L. Harris wrote:
> > > 
> > > 1.  It might be good if you could pass a date as a command line option
> > > to yum ... and have yum not consider anything after that date as being
> > > in the repo.
> > > 
> > > That is a good suggestion for the yum mailing list:
> > > https://lists.linux.duke.edu/mailman/listinfo/yum
> > 
> > Which fails if the repo you are pointing to has to restore the repo
> > files and the datetime stamp changes....
> 
> If you don't restore in a way that maintains the timestamp, every
> mirror is going to have to suck a fresh copy of the whole
> repository.  I'd expect the maintainers to already be careful
> about that.
> 
> > IMHO a completely different application should be used.  This
> > application is mostly a database that tracks a list of rpms.  If you
> > want to build a copy of a system you select the particular snapshot (the
> > list of rpm versions you decided was the image) and the new utility
> > proceeds to pull those rpms from the repo and install them on the target
> > system.  This new application would allow you to create multiple
> > snapshots and select which one you wanted to use.
> 
> That would be better in the sense that it could detect errors
> like files being removed from the repository.  If the
> repository only has additions, the timestamp is all
> you need to recreate the list of rpms that were present at
> any time.  If you are going to the trouble of doing something
> more complicated, it should involve tying repository update
> 'sets' of rpms together so that a client could tell if
> all needed files were present at a mirror site instead of
> just failing dependencies when a partial update requires
> a missing file.
> 
> > Trying to cram this into yum is IMHO going to make yum overly complex
> > and more difficult to use.  
> 
> Repeatable operations are more than just a nice idea in
> the computer world...  And making everyone who wants a
> repeatable yum update store a whole repository snapshot
> for every point they need just doesn't seem like an
> efficient way to get that.

I think you missed the point.  The new application stores a list of the
rpms that make up your snapshot not the actual rpms.  You can have many
snapshots in the database.  The repo is just that a repo of packages. 
The new app pulls the packages that are part of your snapshot.  Of
course if you were doing this for a large enterprise you would be
running your own repo anyways with packages moved from a testing repo to
the staging and then production repos as you verify each package does
what is expected.  That is how you get your repeatable operations.

But then I think this has been discussed previously several times in
this thread.  

Nothing of value will come from any further discussion of this topic in
this thread.