headers
Florian La Roche | 3 Oct 2005 12:25
Picon
Favicon

adding more information to repo metadata

I've added the below text to http://people.redhat.com/laroche/pyrpm/README.html
Adding the "flag" part of dependencies also as integer into the repodata would
make it more complete and useful for new tasks.

greetings,

Florian La Roche

Notes about the Repo-Metadata
-----------------------------

The following things should be noted about the repo metadata. yum is using
the repodata only within the resolver part, then downloads the rpm headers
and passes all the headers on to rpmlib to verify again if the resolver
of rpmlib is ok as well as doing e.g. the installation ordering part
within rpmlib. If the repodata would be more complete, more steps could
be done only based on the repodata being available:

 - Even if no epoch is specified, the metadata still specifies this as "0".
   For most code paths this is no problem as for all comparisons of version
   data, a missing epoch is the same as a "0" epoch. This should not be
   a huge problem and would be only a cleanup item for the repodata.
 - For dependency information the `flag` part is only partially copied into
   the repodata. Just adding the `flag` information as integer would make
   sure all information is present in any case. Extending the repodata to
   have `intflag` added alongside the old information would be good.
 - Repo data adds a "pre" flag if the RPMSENSE_PREREQ flag is set. That
   information is actually not complete to identify install prereq and
   we need the more complete flag information as requested above to
   be able todo correct installation ordering based on repodata.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Florian La Roche | 3 Oct 2005 12:31
Picon
Favicon

repo metadata written in deterministic order

The following patch for createrepo-0.4.3 makes the creation of
the xml content more deterministic. The last patches also remove
a few newlines, otherwise no data change at all.

greetings,

Florian La Roche

--- createrepo-0.4.1/dumpMetadata.py.lr	2005-10-03 09:25:21.917352873 +0200
+++ createrepo-0.4.1/dumpMetadata.py	2005-10-03 09:25:33.789511255 +0200
 <at>  <at>  -326,7 +326,9  <at>  <at> 
         except TypeError:
             del u  # move on to the next method
         else:
-            return u.keys()
+            ret = u.keys()
+            ret.sort()
+            return ret

         # We can't hash all the elements.  Second fastest is to sort,
         # which brings the equal elements together; then duplicates are
 <at>  <at>  -421,7 +423,7  <at>  <at> 
             for glob in self.filerc:
                 if glob.match(item):
                     returns[item] = 1
-        return returns
+        return returns.keys()

     def usefulGhosts(self):
         """search for useful ghost file names"""
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Nasrat | 3 Oct 2005 17:00
Picon
Favicon

Re: adding more information to repo metadata

On Mon, 2005-10-03 at 12:25 +0200, Florian La Roche wrote:

> Notes about the Repo-Metadata
> -----------------------------
> 
> The following things should be noted about the repo metadata. yum is using
> the repodata only within the resolver part, then downloads the rpm headers
> and passes all the headers on to rpmlib to verify again if the resolver
> of rpmlib is ok as well as doing e.g. the installation ordering part
> within rpmlib. If the repodata would be more complete, more steps could
> be done only based on the repodata being available:
> 
>  - Even if no epoch is specified, the metadata still specifies this as "0".
>    For most code paths this is no problem as for all comparisons of version
>    data, a missing epoch is the same as a "0" epoch. This should not be
>    a huge problem and would be only a cleanup item for the repodata.
>  - For dependency information the `flag` part is only partially copied into
>    the repodata. Just adding the `flag` information as integer would make
>    sure all information is present in any case. Extending the repodata to
>    have `intflag` added alongside the old information would be good.

Something like this makes sense for the work I'm looking at in anaconda
changes for FC5 - I'm a little unsure on the name - maybe "sense" would
be better.   

Do you currently have a patch for this?

Paul
Permalink | Reply | 0 comments |
headers
Jeff Johnson | 3 Oct 2005 18:36
Picon
Gravatar

Re: adding more information to repo metadata


On Oct 3, 2005, at 6:25 AM, Florian La Roche wrote:

> I've added the below text to http://people.redhat.com/laroche/pyrpm/ 
> README.html
> Adding the "flag" part of dependencies also as integer into the  
> repodata would
> make it more complete and useful for new tasks.
>
> greetings,
>
> Florian La Roche
>
>
>
> Notes about the Repo-Metadata
> -----------------------------
>
> The following things should be noted about the repo metadata. yum  
> is using
> the repodata only within the resolver part, then downloads the rpm  
> headers
> and passes all the headers on to rpmlib to verify again if the  
> resolver
> of rpmlib is ok as well as doing e.g. the installation ordering part
> within rpmlib. If the repodata would be more complete, more steps  
> could
> be done only based on the repodata being available:
>
>  - Even if no epoch is specified, the metadata still specifies this
(Continue reading)

Permalink | Reply | 0 comments |
headers
seth vidal | 3 Oct 2005 19:50

Re: [Yum-devel] adding more information to repo metadata

>  - Even if no epoch is specified, the metadata still specifies this as "0".
>    For most code paths this is no problem as for all comparisons of version
>    data, a missing epoch is the same as a "0" epoch. This should not be
>    a huge problem and would be only a cleanup item for the repodata.

what does removing 0-epoch items buy us?

-sv

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Permalink | Reply | 0 comments |
headers
Florian La Roche | 3 Oct 2005 19:53
Picon
Favicon

Re: [Rpm-metadata] Re: [Yum-devel] adding more information to repo metadata

On Mon, Oct 03, 2005 at 01:50:24PM -0400, seth vidal wrote:
> >  - Even if no epoch is specified, the metadata still specifies this as "0".
> >    For most code paths this is no problem as for all comparisons of version
> >    data, a missing epoch is the same as a "0" epoch. This should not be
> >    a huge problem and would be only a cleanup item for the repodata.
> 
> what does removing 0-epoch items buy us?

Hello Seth,

You can change all algorithms looking at epochs
to also first convert all empty epochs to "0" to have things working,
then we don't have to change repodata again. It is just something you
have to keep in mind if working with repodata compared to data from
rpm headers.
Keeping to repodata as deployed right now does make lots of sense,
that's why things are worded as done above.

greetings,

Florian La Roche

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Permalink | Reply | 0 comments |
headers
Paul Nasrat | 6 Oct 2005 16:44
Picon
Favicon

Re: adding more information to repo metadata

On Mon, 2005-10-03 at 11:17 -0400, Jeff Johnson wrote:
> On Oct 3, 2005, at 11:00 AM, Paul Nasrat wrote:

> > Something like this makes sense for the work I'm looking at in  
> > anaconda
> > changes for FC5 - I'm a little unsure on the name - maybe "sense"  
> > would
> > be better.
> >
> 
> The dependency flags were deliberately truncated to that which is  
> guaranteed to be supported.

The more I think about this I tend to agree that we don't really want to
expose the internal representation up to the metadata.

Smart uses what we have now to do ordering and so the current
representation should be sufficient.

Paul
Permalink | Reply | 1 comment |
headers
Jeff Johnson | 6 Oct 2005 18:55
Picon
Gravatar

Re: adding more information to repo metadata


On Oct 6, 2005, at 10:44 AM, Paul Nasrat wrote:

> On Mon, 2005-10-03 at 11:17 -0400, Jeff Johnson wrote:
>> On Oct 3, 2005, at 11:00 AM, Paul Nasrat wrote:
>
>>> Something like this makes sense for the work I'm looking at in
>>> anaconda
>>> changes for FC5 - I'm a little unsure on the name - maybe "sense"
>>> would
>>> be better.
>>>
>>
>> The dependency flags were deliberately truncated to that which is
>> guaranteed to be supported.
>
> The more I think about this I tend to agree that we don't really  
> want to
> expose the internal representation up to the metadata.
>
> Smart uses what we have now to do ordering and so the current
> representation should be sufficient.
>

Cool, knew you were sane. ;-) Meanwhile, it would be nice to get  
dependency context
and colors (but not PreReq, sigh) exposed, that information is useful  
for diagnostic purposes and more.

But please, not by value. E.g. dependency flags are almost all used
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erich Focht | 31 Oct 2005 11:50
Picon

test if repomd up to date?

Hi,

is there an easy and cheap test whether the repository metadata is up-to-date?
It would be great to have some --check option integrated into createrepo...

Thanks,
best regards,
Erich
Permalink | Reply | 5 comments |
headers
seth vidal | 31 Oct 2005 19:51

Re: test if repomd up to date?

On Mon, 2005-10-31 at 11:50 +0100, Erich Focht wrote:
> Hi,
> 
> is there an easy and cheap test whether the repository metadata is up-to-date?
> It would be great to have some --check option integrated into createrepo...
> 

Not really - closest thing is the cache option in createrepo 0.4.3

-sv
Permalink | Reply | 4 comments |

Gmane