[tools] mrepo/yam groupfile path weirdness

Francois Aucamp faucamp at csir.co.za
Tue May 15 09:48:56 CEST 2007


Tested, and it works great, thanks. :-) 

Also, getting the version number from python itself is much more
elegant. The only *really* *really* small potential problem with this
method is the hard-coded location of the genpkgmetadata module
("/usr/share/createrepo") - as it potentially renders the configuration
option "createrepocmd" semi-useless... (if, for instance, the user has
multiple different copies of createrepo installed and is using a
different installation path for some strange reason). However, this
location is very unlikely to ever change, especially not on a
RH/Fedora-based system, so I don't see a real problem with this.

Cheers,
-Francois
 

>>> Dag Wieers <dag at wieers.com> 05/14/07 8:09 PM >>> 
On Mon, 14 May 2007, Francois Aucamp wrote:

> > >>> Dag Wieers <dag at wieers.com> 05/14/07 4:32 PM >>> 
> > On Mon, 14 May 2007, Francois Aucamp wrote:
> > 
> > > I'm not sure if anyone else has this issue, but since comps.xml
> > > support was added to yam proper (0.8.2 iirc), I've had an issue
with 
> > > the location of the group file that is passed to "createrepo" in
> > > repomd():
> > > it adds another RPMS.x/ subdir to the pathname, which causes
> > > createrepo to not see the symlinked comps.xml file:
> > > 
> > > $ mrepo -  gvvv fc5-  x86_64
> > > <snip>
> > > fc5-  x86_64: Create repomd repository for os
> > > Error: groupfile /var/www/mrepo/fc5-
x86_64/RPMS.os/RPMS.os/comps.xml
> > > cannot be found.
> > > <snip>
> > > 
> > > Note the two "RPMS.os" entries in the above error message. mrepo
in
> > > svn does the same (the code responsible is identical). This is 
> > > _very_ simple to fix (see attached patch for mrepo-  0.8.4); my 
> > > setup has always been rather *ahem* modified, so this didn't come
up 
> > > until I decided to finally upgrade my old yam setup.
> > > 
> > > With the patch applied everything works fine. Can anyone
duplicate
> > > this problem? Or am I simply missing something here..? (it's been

> > > awhile since I've configured a clean yam/mrepo)
> > 
> > Yes, known issue. Problem resides with the different createrepo
> > versions. 
> > Use the one from RPMforge (0.4.6) which is newer than what is
provided
> > by RHEL5.
> > 
> > It's unfortunate that they changed something like this without any

> > backward compatibility. I prefer to stick with the newer way of
doing
> > it.
> > 
> > Maybe I should add a dependency to 0.4.6 specifically ?
>
> This was done on a Fedora 5 machine, and apart from Axel Thimm's
> packages I can't seem to find any newer fedora5/6 createrepo pkgs
(not a
> big problem since it's noarch)... anyway, since f7 ships with 0.4.8,
> this won't be an issue for very long (at least for fedora).
> 
> In the meantime, I've whipped up a patch (attached) that checks the
> installed createrepo version, and modifies the -- groupfile switch
> accordingly -  I'm afraid that a hard dependency on 0.4.6 might
scare
> some people away.

I agree with you and I'm very grateful that you send in a patch. I 
modified it slightly to not parse the -- version output but instead
import 
the class and get a version within python. And if that fails, I assume
it 
is newer than 0.4.6.

Also the version comparison is now done by an additional function. You

never know when we'll need that in the future.

Please test it, since I haven't got a system currently using an older 
createrepo or the same setup I'm interested to hear if this works.

Kind regards,
--    dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]


-- 
This message is subject to the CSIR's copyright, terms and conditions and
e-mail legal notice. Views expressed herein do not necessarily represent the
views of the CSIR.
 
CSIR E-mail Legal Notice
http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html 
 
CSIR Copyright, Terms and Conditions
http://mail.csir.co.za/CSIR_Copyright.html 
 
For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR
Legal Notice send a blank message with REQUEST LEGAL in the subject line to
CallCentre at csir.co.za.


This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.



More information about the tools mailing list