Amit Laxmikant Pande wrote:
Not sure if already this item is on the "TO DO" list.
*The use case:*
For all the Linux patches, hosted on YUM repositories, I would like to
see only security patches and then I can decide if I wish to mirror them.
*Current solution:*
For YUM repositories, we have *patches.xml* which maintains few details
about all the patches hosted on that particular repository and then
links to the individual patch-XXXX.xml files.
Some sample patches.xml file:
_/http://download.opensuse.org/update/10.3-test/repodata/patches.xml/_
So if I just want to see security patches, I need to go through the
parent patches.xml file and then through all the individual patch files.
Since we need to parse all the patch files (there may be few hundreds of
patches hosted on a YUM repository on an average), the listing becomes
*tremendously slow *and giving a *not so pleasant user experience*.
And the use case of someone (mainly the administrator managing IT
infrastructure of any organization ) willing to see only certain type of
updates is *pretty widely used.*
*Suggestion:*
Can we move (or copy,for that matter) this patch category (security,
recommended, optional) information in the patches.xml only so that by
parsing just one XML file I can get what I want within a quick time ?
Is there any subtle reason for not doing this so far ?
Any feedback on the same is welcome.
Thanks,
Amit
The 'patches' metadata is not part of yum's standard metadata, so it
must be parsed by some addon code not in upstream yum. So the RFE you
are asking about must be pointed to the maintainer of the addon code.
An idea for improved performance it to put the parsed xml data into a
sqlite db and put it into ../repodata/patches.sqlite.gz and change the
addon code to get the sqlite database directly, this is the way the
standard yum metadata is handled today.
Tim
_______________________________________________
Yum mailing list
Yum@xxxxxxxxxxxxxxxxxxxx
https://lists.dulug.duke.edu/mailman/listinfo/yum
