[Yum] using createrepo to provide repodata for fedora-core iso

[David Timms]

David Timms wrote: {adding info to coupla-week old thread}
> Tim Lauridsen wrote:
>> David Timms wrote:
>>> Anyone know how to use createrepo {or is there another tool} to 
>>> create useful repodata for a mounted dvd.iso image for say fedora core.
>>>
>>> It seems that while the image includes a toplevel /repodata folder, 
>>> when it is mounted and yum.repos.d/fedora-core.repo is pointed at the 
>>> / of the mounted iso image, yum is not happy with what it finds.
>>>
>>> I have used createrepo folder option to create a new repodata 
>>> directory and repo one folder above where the iso is mounted, so that 
>>> the folder is read/write, and the create can succeed.
>>>
>>> createrepo -o . disc/Fedora/RPMS/
>>>
>>> What I find is that primary.xml does not include the relative path 
>>> from the folder above the new repodata directory, and hence fails. 
>>> {actually it includes only the filename of the rpm files not any path 
>>> at all.}
>>>
>>> folder where iso is mounted:
>>> /home/install/software/linux/fedora/core/6/yum/i386/disc
>>>
>>> location of rpms:
>>> /home/install/software/linux/fedora/core/6/yum/i386/disc/Fedora/RPMS
>>>
>>> writable location: {where yum.repos.d/fedora-core.repo baseurl will 
>>> point}
>>> /home/install/software/linux/fedora/core/6/yum/i386/
>>>
>>> What is the appropriate command to generate usable repodata ?
>>>
>>> DaveT.
>> Check this howto:
>>
>> http://www.city-fan.org/tips/YumRepoFromImages
> Paul's tip can work, but I found that there is another requirement: the 
> r/w folder {i386} where subdir where .iso will be mounted {disc} must 
> not have any other .rpm files any peer subdirs. Since my machine is laid 
> out:
> /home/install/software/linux/fedora/core/6/i386/
> /home/install/software/linux/fedora/core/6/i386/disc {dvd mounted here}
> /home/install/software/linux/fedora/core/6/i386/disc/Fedora/RPMS
> /home/install/software/linux/fedora/core/6/i386/yum {normal yum cache, 
> keepcache=1, so that cache doesn't fill up /var partition}
> 
> If I then:
> $ cd /home/install/software/linux/fedora/core/6/i386/
> $ createrepo .
> repodata is created at:
> /home/install/software/linux/fedora/core/6/i386/repodata
> as expected, but the primary.gz includes all the rpms from the other yum 
> folder {updates/extras and other repositories}.
> 
> If there is no other way to generate repodata in this situation, then I 
> would like to suggest that an additional option needs to be added to
> createrepo.
> --include=dir-to-include.
> 
> Any thoughts on whether such a command option should be implemented ?
Hi, I thought my local fedora core 6 dvd repo using info from 
http://www.city-fan.org/tips/YumRepoFromImages , and what I subsequently 
learned about making sure there is no other rpms in any subdir under the 
folder that is the target for createrepo, was succesful.

However, I performed a definite test by #commenting out other 
fedora-core.repo baseurls and mirror settings, leaving only my local 
repo entry.

This did not work. For example, even though createrepo was run at one 
folder higher than where the dvd...iso is mounted {so that the repodata 
folder can be created}, and during the process the rpm paths are shown 
as disc/Fedora/RPMS/aa....i386.rpm, yum would fail to retrieve the 
package information.

With debug yum -d 15, I could see that it was trying to download from 
my-path/Fedora/RPMS/... rather than
my-path/disc/Fedora/RPMS/... which is where the files exist.

Redoing the process, into a new folder {dvd}, I found that still the 
incorrect path was being used. primary.xml {one extracted} definitely 
shows the paths as dvd/Fedora/RPMS/whatever.rpm

For more reliable tests, I ran yum clean metadata between test runs. It 
hit me that something is still storing these old {incorrect} paths, in 
fact the sqlite cache is still present on disk.

yum clean dbcache and then tested again. Works perfectly {picks up the 
paths that are actually in the repo being requested}. :-)

This seems to be a fault in the way yum handles the sqlite db. While 
there is a workaround {the motto should be "it just works" rather than 
"you just need to find and do this workaround"}, to get around the 
problem, would it be possible for yum to determine itself that it needs to:
- adjust the paths within the sqlite db ,and/or
- rebuild the sqlite db from scratch ?

David Timms.