headers
seth vidal | 3 Dec 2003 08:51

updates

Hi all,
 some trivial updates to the repository generation scripts:
 http://linux.duke.edu/metadata/generate/

I was also thinking some about the repository description file and it's
purposes/goals.

right now it looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<repository> 
  <name>some name for human consumption</name>
  <contact>somedude <at> someplace.org</contact>
  <description>some text description</description>
  <key type="gpg">http://path/to/my/gpg-pubkey</key>
  <key type="gpg">http://path/to/his/gpg-pubkey</key>
  <metadata>
    <data type="primary" timestamp="1068793003" href="relative/path/to/primary.xml"/>
    <data type="filelist" timestamp="somenumber" href="relative/path/to/filelists.xml"/>
    <data type="other" timestamp="somenumber" href="relative/path/to/other.xml"/>
    <data type="groups" timestamp="somenumber" href="relative/path/to/groups.xml"/>
  </metadata>
</repository>

which is fine  - but the stuff outside of <metadata> is really not
appropriate for what  is being described.

It seems to me that it would be useful to have a more static file that
describes the repository and points to a this file that contains the
entries about the actual metadata file.
(Continue reading)

Permalink | Reply | 2 comments |
headers
seth vidal | 3 Dec 2003 08:59

Re: updates

> It seems to me that it would be useful to have a more static file that
> describes the repository and points to a this file that contains the
> entries about the actual metadata file.

Some more information here:
A repository might look like this:
/myrepo/repository.xml
        repomd.xml.gz
        primary.xml.gz
        filelists.xml.gz
        other.xml.gz
        groups.xml.gz

primary, other and filelists are generated from the rpms
groups is the file we described before for groups of packages
repomd contains timestamps/checksums for the other xml.gz files
repository.xml contains the name, contact, description, keywords, etc
info for the repository. This is not gzipped to be more human readable
and b/c it will be obviously small.

There has been an ongoing discussion on other lists and irc
channels(mostly having to do with fedora, admittedly) on how to do
repository mgmt so user's don't need to edit config files to add a
repository, this is why I'm bringing this up here.

comments appreciated.
-sv
Permalink | Reply | 1 comment |
headers
seth vidal | 5 Dec 2003 08:20

more code and an idea

Hi all,
 So I wrote the repomd generating code - and incorporated it all in one
command for the genpkgmetadata script.

the repomd.xml file is _just_ describing the timestamps and md5sums and
locations of the other metadata files. no other information about the
repo is being housed there in this take on things. Please tell me what
you think about this for the format.

Also,  I was talking to someone from ximian in irc the other day and
they mentioned a need for versions in the groups/comps file.

ie:
 <group>
   ...
   <packagereq name='foo'>
     <version epoch="1" ver="1.1.19" rel="12"/>
   </packagereq>
 </group>

Is that something other people would be interested in? would this work
out overall?

-sv
Permalink | Reply | 4 comments |
headers
Daniel Veillard | 5 Dec 2003 09:46
Picon
Favicon
Gravatar

Re: more code and an idea

On Fri, Dec 05, 2003 at 02:20:30AM -0500, seth vidal wrote:
> Also,  I was talking to someone from ximian in irc the other day and
> they mentioned a need for versions in the groups/comps file.
> 
> ie:
>  <group>
>    ...
>    <packagereq name='foo'>
>      <version epoch="1" ver="1.1.19" rel="12"/>
>    </packagereq>
>  </group>

  Hum, it's actually a case where I think the extra structure brings nothing
    <packagereq name='foo' epoch="1" ver="1.1.19" rel="12"/>
looks just as good unless you start making complex composition within 
one packagereq ...

> Is that something other people would be interested in? would this work
> out overall?

  Well, well, how far are we from closing the initial goal of providing the
metadata needed for tools like up2date, yum, apt, red-carpet when they build
a package update/lookup transation ? I would feel far more comfortable pushing
for new additional formats once we have done at least the first round of
experiment generating those data, testing with at least a pair of tools and
made the first round of public testing. So what is needed now to make
progress toward that initial goal ?

Daniel
(Continue reading)

Permalink | Reply | 3 comments |
headers
seth vidal | 5 Dec 2003 09:47

Re: more code and an idea


>   Hum, it's actually a case where I think the extra structure brings nothing
>     <packagereq name='foo' epoch="1" ver="1.1.19" rel="12"/>
> looks just as good unless you start making complex composition within 
> one packagereq ...

ok - I was trying to reuse the <version> tag we've used elsewhere but I
do see your point.

>   Well, well, how far are we from closing the initial goal of providing the
> metadata needed for tools like up2date, yum, apt, red-carpet when they build
> a package update/lookup transation ? I would feel far more comfortable pushing
> for new additional formats once we have done at least the first round of
> experiment generating those data, testing with at least a pair of tools and
> made the first round of public testing. So what is needed now to make
> progress toward that initial goal ?

>From my perspecive if we want to close as is we can do it more or less
now. I think the groups format needs some more nailing but the metadata
itself is in pretty good shape for me.

I'd like to see what malcolm came up with for docs on justifications and
then I'd like to setup a webpage describing all of this stuff.

Of course all this is contingent on the consensus of others on the list.

Thanks
-sv
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jeff Licquia | 5 Dec 2003 17:36

Architecture support

Catching up after a bit of busyness on other fronts.  Everything looks good.

I did have a thought regarding repomd.xml that I thought would be good 
to bring up.  Sorry if this is a little late to bring up; it's not 
critical, but would be nice.

In apt, you can set up repositories such that the reference in 
sources.list is not architecture-specific.  This is possible because apt 
does some interpretation of the fields in sources.list and builds URIs 
from them using a standard algorithm.

Obviously, such a scheme can't be built into the rpm-metadata stuff. 
But we could allow for an architecture attribute on the metadata node, 
something like this:

<metadata arch="i386">
   <data type="primary"/>
   <data type="filelist"/>
   <data type="other"/>
   <data type="groups"/>
</metadata>
<metadata arch="powerpc">
   <data type="primary"/>
   <data type="filelist"/>
   <data type="other"/>
   <data type="groups"/>
</metadata>

The attribute could be optional, in which case it's assumed that the 
repository is correct.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeff Licquia | 5 Dec 2003 17:59

Re: updates

seth vidal wrote:
> There has been an ongoing discussion on other lists and irc
> channels(mostly having to do with fedora, admittedly) on how to do
> repository mgmt so user's don't need to edit config files to add a
> repository, this is why I'm bringing this up here.

You might be interested in the work I did for aptconf, a configuration 
system for apt.  It's heavily Debian-specific, but the general idea 
could be adapted to RPM easily.

Basically, aptconf reads XML repository description files, and provides 
a UI for enabling and disabling repositories, adding manual 
repositories, etc.  It then writes a sources.list based on the user's 
choices.

Here's an example of the XML file:

<?xml version="1.0"?>
<repositories>
   <repository name="debian-stable" pkgformat="deb">
     <description lang="en">Debian 3.0 - main repository</description>
     <mirror location="at">http://ftp.at.debian.org/debian</mirror>
     <!-- full mirror list snipped -->
     <suite>stable</suite>
     <component free="yes" standalone="yes">main</component>
     <component free="yes">contrib</component>
     <component>non-free</component>
     <binary/>
     <source/>
   </repository>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Malcolm Tredinnick | 6 Dec 2003 01:26
Picon
Favicon

Re: more code and an idea

On Fri, 2003-12-05 at 19:47, seth vidal wrote:
[...]
> I'd like to see what malcolm came up with for docs on justifications and
> then I'd like to setup a webpage describing all of this stuff.

I shall finish up a draft this weekend and post something.

Malcolm
Permalink | Reply | 1 comment |
headers
seth vidal | 6 Dec 2003 20:40

Re: more code and an idea

On Fri, 2003-12-05 at 19:26, Malcolm Tredinnick wrote:
> On Fri, 2003-12-05 at 19:47, seth vidal wrote:
> [...]
> > I'd like to see what malcolm came up with for docs on justifications and
> > then I'd like to setup a webpage describing all of this stuff.
> 
> I shall finish up a draft this weekend and post something.
> 

Thanks Malcolm, That'd be great!

-sv
Permalink | Reply | 0 comments |
headers
seth vidal | 8 Dec 2003 08:16

generate script update

Hi,
 I wasn't calling doc.encodeSpecialChars() on contents so &'s weren't
being encoded to &amp; I had noticed that < and > and " were being
handled so I thought it was happening automatically.

Anyway - the script has been updated at:

http://linux.duke.edu/~skvidal/metadata/generate/

Thanks
-sv
Permalink | Reply | 0 comments |

Gmane