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.'