On Tue, 2005-09-13 at 21:21 -0500, Les Mikesell wrote:
> Yes, there is no argument that yum would have to change.
> However it could be a small change.
Ah ... no, it's _more_ than a "small change." Simply timestamping and
tracking timestamps will _not_ do what you want.
> Yes, but what you really want to do is give the client
> the least he needs to make what it has into what it
> wants. You are always going to be going forward and
> clients that update regularly will always need only
> the diff between the current and last prior RPM.
But that adds to the start-up time. The more meta-data you generate to
do what you want, the longer this stuff will take on the client side.
> If you work only 2 revs at a time there is no difference.
Can you guarantee this?
> Yes, one file for the difference between any two revs which
> is almost always what you want - or you should be updating
> more often. If you need to repeat the process with multiple
> steps, the client can easily calculate whether it is better
> to collect multiple deltas and apply them or just grab the
> complete version it wants.
Again, this is not a "small change" like you think it is.
> So be sensible about what you keep around and make the
> client fall back to existing procedure if the delta
> it might use isn't there.
Again, this is not a "small change." And you're going to start
introducing loads at the server if you try to keep transfer sizes down.
> Keep only 1 or 2 delta/patch files for the latest revs where
> the traffic will actually be happening and thus reduced. In
> the unlikely event you want something else, use the existing
> procedure.
More subjective approaches. What happens if the respositories don't do
what you want? Better yet, how can you ensure all repositories are so
synchronized?
I mean, I saw complaints about repositories not offering the same
packages. It will only get worse when you start timestamping, using
deltas, etc...
> I didn't realize that you wouldn't call them deltas unless
> you cram more than one in the same file. Do you call the
> first one a patch, then change the name when you append the
> next run? The piece everyone will want is currrent-1->current
> so the most benefit would come from keeping that in it's
> own file.
Are you so sure? Sometimes there are more than one update. In fact,
this still does not solve the problem of the fact that repositories
change every few days, and gives you a way to timestamp and resolve all
those changes.
I think people are asking for the "holy grail" here and calling it a
"small change" without thinking through the real issues. A lot of what
I see above is _not_ "tied down" into a methodical approach and more
like "subjective" and making the chances of inconsistency even worse.
--
Bryan J. Smith b.j.smith@xxxxxxxx http://thebs413.blogspot.com
----------------------------------------------------------------------
The best things in life are NOT free - which is why life is easiest if
you save all the bills until you can share them with the perfect woman
