groups-sample.xml and groups.dtd are misleading a bit

Hi Seth et.al.,

today I tackled the yum group setup on my local SuSE 9.3 systems.
First, I've created a script to convert the SuSE .sel(ection) files into 
the yum preferred xml format, based on your nice yumgengroups.py.
During that course, I came across an inconsistency in 
http://linux.duke.edu/projects/metadata/samples/groups-sample.xml and
http://linux.duke.edu/projects/metadata/dtd/groups.dtd: the <groupid> 
tag. Simply using <id>, like yumgengroups.py does, works as expected.
Would you throw this script into yum/download/misc?

BTW: the createrepo man page raised the question, in which repo the 
group definition file should/can go? All repos, the first, any ...

Could you elaborate a bit, how the different type definitions of 
groupreq and packagereq tangent yum?

Your script makes sure, that only real rpms will pass. SuSE on the other 
hand, uses heavily the feature to just ignore unresolvable packages, 
e.g. they have many *-32bit packages in their groups: they're 
inexistent in the ia32 world, but came to existence on x86_64..

AFAICS, yum does ignore unresolvables silently, too. Can I depend on 
this feature?

Thanks to this stuff, I successfully installed a SuSE 9.3 default setup 
into an installroot directory with yum today. Great, as this is the 
first major building block to a nice and handy diskless environment.. 
Note: in order to avoid millions of "user/group does not exist" 
warnings (which aren't restorable easily either), I found it necessary 

[Patch] createrepo --check option

Hi Seth,

as promised, here's my first patch for createrepo to suppress metadata 
recreation, if the timestamps are up to date, including documentation 
changes to createrepo.8 and ChangeLog. 

Works fine here, and I would be very happy to get it applied upstream.

If you have any issues with it, tell me, please.

Thanks,
Pete

P.S.: Could you say a few words to the message right above this one?
      Or to be more concise, can I use different group.xml files on
      different repos and any group definition in them with yum?

Re: [Patch] createrepo --check option

and here's the missing patch :

_______________________________________________
Rpm-metadata mailing list
Rpm-metadata <at> lists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-metadata

Re: groups-sample.xml and groups.dtd are misleading a bit

On Mon, 2005-05-09 at 00:33 +0200, Hans-Peter Jansen wrote:
> Hi Seth et.al.,
> 
> today I tackled the yum group setup on my local SuSE 9.3 systems.
> First, I've created a script to convert the SuSE .sel(ection) files into 
> the yum preferred xml format, based on your nice yumgengroups.py.
> During that course, I came across an inconsistency in 
> http://linux.duke.edu/projects/metadata/samples/groups-sample.xml and
> http://linux.duke.edu/projects/metadata/dtd/groups.dtd: the <groupid> 
> tag. Simply using <id>, like yumgengroups.py does, works as expected.
> Would you throw this script into yum/download/misc?
> 

yah - the problem is that the group definition proposed there is not
what the ACTUAL group stuff in yum is using. Yum is using the striaght
(and somewhat weird) comps.xml format from red hat. It's also a
notoriously undocumented format. Check out comps.xml from a fedora or
rhel release and you'll see how it works.

> BTW: the createrepo man page raised the question, in which repo the 
> group definition file should/can go? All repos, the first, any ...

any.

> Could you elaborate a bit, how the different type definitions of 
> groupreq and packagereq tangent yum?

go into yum look at groups.py and read the big comment block at the top.
I think that will help explain it a bit.

Follow-up on some old issues

Hi everyone,

I'm working on bringing together red-carpet and the package management
components of YaST.  The plan right now is to use the format from this
metadata project with some extensions, of course.  I was wondering what
the status was of two issues discussed on the list last year.

First, back in December, Seth brought an idea involving tags for
relating package entries to removable media and the thread seems to have
just died.  Did anything come of this?  If there is nothing standard,
have any other projects added extensions that do this?  I'm interested
in this since we want to try and leverage the same, or very similar,
metadata on our update servers as well as on our installation media.

Second, going even further back in time to August of 2004, Seth brought
up the idea of linking multiple repositories together.

"I'm asking b/c it would be an interesting experience to create a
distribution 'tree' that was a set of metadata repositories tied
together by a central metadata repo that used referrals to find other
items."

Anything ever come of this?

Thanks for the help.

~jose

[Patch] createrepo --check option take two

Hi Seth,

Here's a slightly reworked version of the --check option, it now checks 
the directory timestamp, containing the rpm, as it happened, that an 
older rpm appeared today in one of my rsyned suse update repos (due to 
some internal lags), which didn't triggered the rebuild, then.. 

As a nice plus, the number of stats are greatly decreased, if a dir in 
the repo is not up to date (not that it matters, compared to the 
following repo rebuild...). 

Do you think, it's worth to include it upstream now?

	Pete

_______________________________________________
Rpm-metadata mailing list
Rpm-metadata <at> lists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-metadata

Re: Follow-up on some old issues

Hi Jose,
 Sorry for the long delay - I was out of town for a few days and not
answering much email.

> First, back in December, Seth brought an idea involving tags for
> relating package entries to removable media and the thread seems to have
> just died.  Did anything come of this?  If there is nothing standard,
> have any other projects added extensions that do this?  I'm interested
> in this since we want to try and leverage the same, or very similar,
> metadata on our update servers as well as on our installation media.

nothing came of it - but it's still needed. The ability to associate a
package with a specific piece of removable media is important.

> 
> Second, going even further back in time to August of 2004, Seth brought
> up the idea of linking multiple repositories together.
> 
> "I'm asking b/c it would be an interesting experience to create a
> distribution 'tree' that was a set of metadata repositories tied
> together by a central metadata repo that used referrals to find other
> items."
> 
> Anything ever come of this?

no progress on that, either. The major problem from there came out of
how you specify and gather that information in an way you can automate.

-sv

Re: [Patch] createrepo --check option take two

On Tue, 2005-05-24 at 12:07 +0200, Hans-Peter Jansen wrote:
> Hi Seth,
> 
> Here's a slightly reworked version of the --check option, it now checks 
> the directory timestamp, containing the rpm, as it happened, that an 
> older rpm appeared today in one of my rsyned suse update repos (due to 
> some internal lags), which didn't triggered the rebuild, then.. 
> 
> As a nice plus, the number of stats are greatly decreased, if a dir in 
> the repo is not up to date (not that it matters, compared to the 
> following repo rebuild...). 
> 
> Do you think, it's worth to include it upstream now?

quite possibly, yes.

There are some other things I'd like to see done to the format/program
as well:
1. make the checksum be an internal package checksum and/or store a
cache of package checksums and rebuild based on timestamp change (for
quicker re-indexing of a repo)

2. split out the metadata some more as described a few months ago

3. work on any ways to make the repo creation as fast as possible.

-sv