Maybe this is just a "me" thing and I should use different caches, but when I try to use the same cachedir and compose i686 and x86_64 images, I can run into a situation where the repomd.xml for say the 64bit repo is newer than the repomd.xml for the 32bit repo. This can lead to a situation where livecd-creator won't pull down the repodata for the 32bit repo after a 64bit run, which will lead to the compose crashing horribly.
With pungi, I force re-getting all the repodata, regardless of existing content. It's a little extra downloading but it ensures we always get the right repodata. Do people think that's what should be done with livecd-creator, or should I just set up my scripts so that when composing i686 I use one cache dir, and when composing x86_64 I use another?
On Mon, 2008-10-06 at 17:38 -0700, Jesse Keating wrote:
Maybe this is just a "me" thing and I should use different caches, but when I try to use the same cachedir and compose i686 and x86_64 images, I can run into a situation where the repomd.xml for say the 64bit repo is newer than the repomd.xml for the 32bit repo. This can lead to a situation where livecd-creator won't pull down the repodata for the 32bit repo after a 64bit run, which will lead to the compose crashing horribly.
With pungi, I force re-getting all the repodata, regardless of existing content. It's a little extra downloading but it ensures we always get the right repodata. Do people think that's what should be done with livecd-creator, or should I just set up my scripts so that when composing i686 I use one cache dir, and when composing x86_64 I use another?
The default is that we use a fresh cache directory for each individual run. If you're reusing cachedirs, you should either be keeping them arch-specific or just nuke metadata yourself in between runs. I'd really prefer keeping any information about how repos are built, verified, etc out of livecd-creator as it's just another thing that can get out of sync over time
Jeremy
On Mon, 2008-10-06 at 20:49 -0400, Jeremy Katz wrote:
The default is that we use a fresh cache directory for each individual run. If you're reusing cachedirs, you should either be keeping them arch-specific or just nuke metadata yourself in between runs. I'd really prefer keeping any information about how repos are built, verified, etc out of livecd-creator as it's just another thing that can get out of sync over time
I wouldn't think that unconditionally cleaning out repodata (at least the repomd.xml file) each run would be 'information about how repos are built, verified, etc' but maybe that depends on the 'etc'.
On Mon, 2008-10-06 at 17:59 -0700, Jesse Keating wrote:
On Mon, 2008-10-06 at 20:49 -0400, Jeremy Katz wrote:
The default is that we use a fresh cache directory for each individual run. If you're reusing cachedirs, you should either be keeping them arch-specific or just nuke metadata yourself in between runs. I'd really prefer keeping any information about how repos are built, verified, etc out of livecd-creator as it's just another thing that can get out of sync over time
I wouldn't think that unconditionally cleaning out repodata (at least the repomd.xml file) each run would be 'information about how repos are built, verified, etc' but maybe that depends on the 'etc'.
The fact that it's repomd.xml is an implementation-detail that there's no real business for livecd-creator to need to know. And while repomd.xml hasn't changed, we definitely have changed similar things in the past (rest of the metadata being xml -> sqlite)
Jeremy
On Mon, 2008-10-06 at 21:21 -0400, Jeremy Katz wrote:
The fact that it's repomd.xml is an implementation-detail that there's no real business for livecd-creator to need to know. And while repomd.xml hasn't changed, we definitely have changed similar things in the past (rest of the metadata being xml -> sqlite)
Er, I'm not asking for a manual rm, rather a yum API call to clean out the repodata, surely that's not too specific?
livecd@lists.fedoraproject.org
-
Jeremy Katz -
Jesse Keating -
Jesse Keating