[users] Metadata broken for *at least* rh9

Dag Wieers dag at wieers.com
Fri May 9 11:52:28 CEST 2008


On Thu, 8 May 2008, Rex Dieter wrote:

> Dag Wieers wrote:
>> On Thu, 8 May 2008, Ralph Angenendt wrote:
>> 
>>> I just talked to skvidal about
>>> <https://bugzilla.redhat.com/show_bug.cgi?id=444882> - looks like the
>>> metadata in *at least* the rh9 repository is broken (no, I know that rh9
>>> isn't rawhide9, but that doesn't matter ...).
>> 
>> The metadata is not broken, yum is broken.
>> 
>> Seth is the sole reason why we have this situation. The createrepo metadata 
>> was not designed with backward compatibility in mind and therefor does not 
>> understand the situation where the epoch is unset (which is the case for 
>> older distributions).
>
> joy,
> https://bugzilla.redhat.com/show_bug.cgi?id=444882
>
> The metadata DTD (as written, according to Seth anyway), pretty much requires 
> it.

Why then does the createrepo -n option exists that resulted in that "badly 
broken" metadata output ?

      -n, --noepoch = don't add zero epochs for non-existent epochs
                     (incompatible with yum and smart but required for
                      systems with rpm < 4.2.1)

The fact that the epoch-field is mandatory in the repomd metadata 
definition is an oversight and the easiest way to rectify that situation 
is to change the metadata definition so that repomd can be used on RH9 and 
older, like apt is currently already doing.

That way the "createrepo -n" is no longer necessary and createrepo can 
handle it automagically in all cases and that clears the path for yum to 
implement it as well.

The change is pretty simple, the implementation already exists and patches 
are available to do it. The only thing holding us back is the power to 
change.

In any case, stating that the RPMforge metadata is corrupt is an 
oversimplification of the problem. It is either doing it like we do (and 
support apt) or not generate any metadata at all. Or we can dismiss this 
for a few years (like the past couple of years) and the problem will 
resolve itself... -sigh-

-- 
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]


More information about the users mailing list