--- "Bryan J. Smith" b.j.smith@ieee.org wrote:
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@ieee.org 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
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
sir_funzone pulls out the shotgun and aims, calls the word pull, seeing the thread Re: [CentOS] Why is yum not liked by some? in his gunsite. Pulls the trigger and hears the load pop of the shotgun going off, hoping the sluge will hit its target. Whamo target sought and hopefully destroyed with exploding force that it is never seen again..... waiting to see if that little rascal has survived, sir_funzone reloads his shotgun and points it toward the direction of the thread Re: [CentOS] Why is yum not liked by some? hoping not to see it come alive again...
Steven
"On the side of the software box, in the 'System Requirements' section, it said 'Requires Windows or better'. So I installed Linux."