Bug 993567

Description of problem:

I package several site-specific programs into rpm packages and have a local repository for those rpms. This is on a disk, which is local and the .repo file in /etc/yum.repos.d uses file: in the baseurl followed by the path.

After creating a new version of an rpm with a higher version number, and createrepo --update, yum update offers to update this package and prompts "Is this ok [y/d/N]:" Selecting "y" or "n" at this stage is fine. Selecting "d" causes the rpm in the local repository to be renamed, so that it no longer has the architecture and .rpm extension in the filename. This breaks the repository. Renaming the file back manually, makes it work again.

Version-Release number of selected component (if applicable):

yum-3.4.3-104.fc19.noarch

How reproducible:

Always, but the procedure is complicated

Steps to Reproduce:
1. Build a new version of an installed rpm package (with a new version number), sign it and place it in the repository
2. createrepo --update on the repository
3. sudo yum update --downloadonly

Actual results:

Everything looks as though it has worked perfectly, but actually the file in the repository has been renamed. e.g. I had hv_server-20130426-1.fc19.x86_64.rpm installed and created a new version hv_server-20130805-1.fc19.x86_64.rpm and placed it in the local directory and ran createrepo --update. After that, the file was still the same. On running yum update --downonly, the filename changed from hv_server-20130805-1.fc19.x86_64.rpm to hv_server-20130805-1.fc19 (i.e. without the .x86_64.rpm extension).

Note that hv_server is just an example, the same occurs with any package. This just happens to be the one, which annoyed me enough to spend half a morning tracking down the problem!

Expected results:

yum should never alter the repositories. Surely it should just be "downloading" the packages into its cache directory, just like it does for remote repositories? Apparently, that is not the case. Whatever the reason, yum certainly has no business changing _anything_ in the repository.

Additional info:

If I remount the disk where the repository resides readonly just before the yum update --downloadonly, I get:

Traceback (most recent call last):
  File "/bin/yum", line 29, in <module>
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 316, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 219, in main
    return_code = base.doTransaction()
  File "/usr/share/yum-cli/cli.py", line 630, in doTransaction
    problems = self.downloadPkgs(downloadpkgs,callback_total=self.download_callback_total_cb) 
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 2471, in downloadPkgs
    os.rename(po.localpath, rpmfile)
OSError: [Errno 30] Read-only file system

It really should be quite legitimate for a repository to be readonly for yum! It might be nfs mounted.

I guess the comment in __init__.py:2470 "overwriting another copy should not be a problem" was a bit optimistic:) Is this connected with bug 491523? 

It doesn't make any difference if I do createrepo with or without the --update, though obviously it is much faster with.

yum update --downloadonly and yum update followed by entering "d" give identical results, as one would expect.

I had a cron job running yum update --downloadonly at 2.30 AM so it took me a while to figure out how the corruption was appearing in the repository. If I put a new rpm into the repository and there was no previous version of the rpm installed, no problem. If I installed the new rpm straight away, also no problem, but if I left the old version installed overnight, then the next morning the repository was broken. It took me a while to spot the pattern, so I think it was already before I upgraded from F18 to F19.