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