[Rpm-metadata] adding more information to repo metadata
n3npq at mac.com
Mon Oct 3 16:36:59 UTC 2005
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/
> Adding the "flag" part of dependencies also as integer into the
> repodata would
> make it more complete and useful for new tasks.
> 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
> and passes all the headers on to rpmlib to verify again if the
> 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
> 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
> 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.
This is purely a representational issue since
Missing Epoch: and Epoch:0 are to be treated identically.
> - 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.
Only those bits whose values are guaranteed were exposed in rpm-
Furthermore, the values were mapped into a different representation.
Exposing internal rpmlib values as an integer is simply stupid.
> - Repo data adds a "pre" flag if the RPMSENSE_PREREQ flag is set.
> 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.
RPMSENSE_PREREQ is not needed for any purpose (yes there is
a difference in handling loops) since all Requires: used as tsort
Define "need" please. I know of no case where any additional information
to qualify dependencies is necessary or desirable.
> - There is a fixed regex string which specifies the filelist
> for the primary.xml file. In addition also all files are listed if
> they appear in any file requires from the same repository. This
> means that
> you need to download the full filelist once you work on more
> than one
> repository and you have file requirements outside of the fixed
> regex list.
> (Detecting the need for full filelists could be done per-repo to
> a quite good detection algorithm.) Only possible path for this
> is to
> identify problems for several repos where the full filelists
> need to be
> downloaded and to add such a requirement into that repo or
> add a command line option to add such additional requirements
> should then get also written into the repodata).
I have suggested several times that repos generate file lists self-
within a repo, rather than using a rule based on paths.
The suggestion was deemed too much work.
73 de Jeff
More information about the Rpm-metadata