On Feb 3, 2004, at 08:21, seth vidal wrote: > >> And to make things worse: Some mirrors do not have correct permissions >> set for the different directories. >> >> And most of this is outside my control. >> >> To make it easier on my customers I wrote a little shell script which >> extract the possible mirrors from Yellowdoglinuxs mirror page. >> It then proceeds to select the fastest mirror by downloading the >> header.info file. >> That works well, but doesn't guard against that one of the faster >> mirrors has an error in the permissions for the rpm directory. >> >> What I would like is if yum-arch left a known dummy file (dummy.yum?) >> of ex 50K in each directory. Download of this file would guaranty that >> the directory is present and accessible. > > Why not just set the mirrors up that DO have copies as multiple > baseurls > to any given repository - then just use the failover mechanism? > > > Also this putting a yum-arch dummy file in a dir sounds KLUDGY - if > your > mirrors are broken and unreliable then you need better mirrors, you > don't add in an ugly 'fix' like that to yum-arch AND to yum. I think you are missing the point here. A verification file is not necessarily kludgy. Not even if you CAPITALIZE it. I believe the issue here is that yum is for customer use. I have no problem downloading the rpms myself and installing them by hand, but ultimately rpm's were created to provide an easier access to application packages. Your answer is along the lines: "If you don't like the rain - move the clouds". Yes it is an answer. It has little value. Maybe I read your answer wrong. As I stated: most of it is outside my control. Yellowdog puts up the mirror page. They point. I can only follow. My repository is ok. It is automatically checked every 12 hours and an email sent to me and my phone if any problems are detected. But the mirrors? How do you expect me to fix those? Turn up on these peoples doorsteps and spank them? Or hang them by heir neck until hey are dead or until they say they are sorry?(Monty Python) Nah - the issue here is that Yellowdog (terrasoft) amongst their mirrors has one that has spurious problems: <http://ftp.sunsite.utk.edu/ftp/pub/linux/yellowdog//yum/3.0.1/update// headers/kernel-source-0-2.4.22-2g.ppc.hdr> This one is ok (other dir) <http://ftp.sunsite.utk.edu/ftp/pub/linux/yellowdog//yum/3.0/RPMS.main/ /headers/kdoc-2-3.0.0-0.20020321cvs.4.noarch.hdr> You can't see that. The mirror appears up. But it is invalid. To me that clearly is a situation that must be recognized - if you want to target the consumer. And don't give me the ugly stuff. I don't want to tell you how to develop yum. Otherwise I would have sent you a diff file. I try to give you as much input as I can about a problem that is severe to me. Suggest a valid solution. Don't just tell me that the world needs fixing. > Why not just set the mirrors up that DO have copies as multiple > baseurls > to any given repository - then just use the failover mechanism? I have systems all over the world. My fastest mirror is Oregon uni. Terrasoft thinks it is Ibiblio. Oregon is 15 times faster though. So I should select Oregon. How about Japan. My guess is that Oregon is no longer the fastest mirror. I could put it into the script. But why? Terrasoft is the logical unit to maintain the mirror URLs. And face it. Yum is not exactly fast. But that is not the quality I am looking for primarily. Yum is reliable. Much more so than apt-get. Using the fall-over mechanism failed when I used it with sunsite as primary mirror. Right now I am considering two ways of action: 1) putting Yum inside a script so that I detect Yum failures and then just invalidate the mirror and re-search for mirrors. (bYum - betterYum :-)) 2) including non standard test-file urls - which I don't like. I still think the problem is valid: You can fix problems in yum because it is under your control. I can fix my repository because it is under my control. But you still need to be able to recognize if a mirror outside your control has lost integrity. Let me hear what you think, Karsten
