Updating RPMs using binary deltas (demo)

Lamar Owen lowen at pari.edu
Tue Jan 27 17:04:34 UTC 2004


On Tuesday 27 January 2004 02:24 am, Warren Togami wrote:
> For those folks that want to eventually have optional RPM diffs for
> upgrades, please do not continue the discussion here.  Instead if you
> feel so strongly that it is technically good and without drawbacks, then
> implement everything needed and provide a test repository and tools at
> your project site.  Only after you feel your project page, tools, and
> repository are PERFECT, then announce here for testing and comments.

??? While I understand your concerns, Warren, this sounds arrogant.  You may 
not have meant it that way, but it is the way it sounds to me, at least.  
This is not an annnounce list, nor is it the beta list, nor is it the user 
list.  It is the devel list, and this is a development issue.  If it's a 
bandwidth concern of wasting your bandwidth reading this, then you are the 
perfect candidate for a bandwidth saving RPM patch method. 

> I would suggest that you to research the problem that was discussed by
> Debian and Red Hat for at least the past 5 years.  Many smart people
> have looked at this problem.  Try not to repeat the same mistakes and
> learn from their prior discussions.

It is useless to say 'learn from the past problem and discussion' without 
providing at least a small pointer to said discussion.  If signing is the 
problem, it appears that that is being worked on.  And things change enough 
in five years to warrant a fresh look.  Just because some smart people have 
looked at the problem does not mean that the person with the right 
perspective and the right insight hasn't yet looked at the problem.  If where 
to place the baseline is the problem, that is a discussion that can only take 
place here, since the baseline for the update would revolve around the 
releases.  There are, of course, other ways to do it: that's why I've been 
keeping quiet during this latest round of discussions.  I'm finding some 
fascinating points are being talked about that I hadn't thought of.

> Do not discuss it here because generally the elders are totally not
> convinced that it is a good thing to do.

<sarcasm>And one wouldn't want to offend the sacred elders.  </sarcasm>

> However I feel that we have more important things to work on that are
> higher priority, like Fedora Project's infrastructure, so I personally
> wont put any effort into this for at least a year or more.

An RPM diff mechanism qualifies as a part of the infrastructure.  Decisions 
about the mechanism for distributing these diffs is an infrastructure 
concern.  Just because some developers feel threatened by this discussion 
does not mean all do.  And I personally believe and think that this 
discussion belongs here, since this is the group that needs convincing of the 
utility of this approach.  There is a prototype script; let's bang on it.  
The whole mechanism shouldn't have to appear fully formed and tested; 
although I suspect that you would have some objection even then.  Perfection 
is never fully achieved; one man's perfection is another man's 
bug-ridden-mess.  But you are certainly entitled to an opinion of otherwise.  
Of course, the fact the SuSE already has a full infrastructure using a 
similar system that is working, is working well, and is quite well tested is 
not even considered, because it was Not Invented Here.

But if you don't want to participate in this facet of development, then don't.  
Others are.  Others who might not have participated in the facet of 
infrastructure that you are rightly concerned about, maybe are involved in 
this.  But I do agree that rpm-list might be the best venue for this 
discussion.  But it is an appropriate discussion here, too.

My interest in this is due to package sizes for frequently updated components 
(my component, PostgreSQL, fortunately isn't very frequently updated) such as 
the kernel and glibc.  KDE and X updates should benefit as well.

And this part of the infrastructure has the potential to benefit users of the 
dist in a more tangible way than some other parts of the infrastructure.  
IMO, YMMV, etc.  Put simply: 'You can get your updates faster.'
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu





More information about the fedora-devel-list mailing list