On Tuesday 10 May 2005 17:54, Greg Knaddison wrote: > On 5/10/05, Lamar Owen <lowen at pari.edu> wrote: > > Well, one can argue semantics, but it takes two to tango. > So, to stay in your metaphor, if I go out on the dance floor and my > partner steps on my foot because she can't tango, does that make it a > flaw in my dance technique? No. No, but if she steps on your foot, there's two reasons why: she can't dance, or you can't move your feet fast enough. Her misstep has two causes. In this case, yum is getting an RFC2616 compliant response code of 304 as an inappropriate response (after all, 304 is indicated only with a conditional GET and is intended to answer caching questions). Now, the question becomes how yum is doing its GET, and how yum responds to an unexpected 304, which just means Not Modified. The urlgrab routines apparently don't handle this for yum (it's open source; I read the source). Fixable with a little work, really. > If you want to tilt at the windmills by all means, but if you want a > meaningful response the place to get it is a yum mailing list. After having maintained the PostgreSQL RPMset for five years I think I know that. But I also know when to shed load; and adding another mailing list to my inbox and its folders is counterproductive when I pretty well know how the discussion will go, and when I respect Seth enough to not start up on the yum list right now. He has as much e-mail load as I do (1500+ e-mails per day or more is my current load; his is probably higher by a little, I would think). > > I've looked closely at the whole strawman of 'if one repo doesn't work, > > then you might get software installed from a repo where you don't expect > > it to come from' and found it full of holes. > You disagree with the maintainer. You seem to have strong opinions on > this. Seems like it is time for you to find a new tool for the job > or, if you really feel strong in your convictions to fork. As I said, I maintained the PostgreSQL RPM set for the PostgreSQL Global Development Group; my name is in the changelog in the CentOS 4 PostgreSQL RPM (rpm -qi --changelog postgresql for yourself). I have seen the results of the various packaging systems' issues up close and personal, and have been blamed for some of them. I have worked around bugs in RPM and other things; it isn't pleasant. So you're not telling me anything new or that I haven't thought about before. Since I am actually paid to do my job, what I am able to do in the open source world reflects what I am doing in my work; thus, I am working on GNUradio, Zope, and Plone stuff right now instead of maintaining the PostgreSQL RPMs. Hmmm, yum is in python too.... So you might want to rethink your statement, as I'm not a freeloader open-source-wise. But I have to ask: fork yum, or fork CentOS? Why would I need to do either? Is a simple, low-grade disagreement enough to do something as counterproductive as fork something that works Pretty Well? This isn't Slashdot, after all. I also use Apt at the moment; unfortunately apt for rpm is effectively not maintained anymore (as it's not really maintainable; the python code in yum is far more maintainable). There is smart available to replace the apt/synaptic duo. But open dialog about why there is an issue is good, I would think. Push comes to shove I can do my own private version of yum, if I like, for my own uses. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu