Project

Profile

Help

Story #3919

Updated by milan about 2 years ago

If an erratum is released for modular content, it will contain information about a module the RPMs are relevant to.
Information about a module is added to a collection in a pkglist.
Each collection corresponds to one module or to non-modular content.
There can be multiple collections in one pkglist (this is just for information, no changes here, it's this way now).
The module element is *optional*. Absence of the module element means that the collection is for normal non-modular RPMs and should be processed as usual.

Example of the modular errata content can be found in updateinfo.xml in the fixtures repo:
https://repos.fedorapeople.org/pulp/pulp/fixtures/rpm-with-modules/

Here is the snippet of the new format:
<pre>
<pkglist>
<collection short="">
<name>coll_name1</name>
<module name="kangaroo" stream="0" version="20180730223407" context="deadbeef" arch="noarch"/>
<package arch="noarch" name="kangaroo" release="1" src="http://www.fedoraproject.org" version="0.3">
<filename>kangaroo-0.3-1.noarch.rpm</filename>
</package>
<package ... >
...
</package>
</collection>
<collection short="">
<name>coll_name2</name>
...
</collection>
</pkglist>
</pre>

For upload, JSON is usually used, so the format will be:
<pre>
{
"issued": "2015-03-05 05:42:53 UTC",
"pkglist": [{
"name": "coll_name1",
"module": {
"name": "duck",
"stream": "0",
"version": "20180730233102",
"context": "deadbeef",
"arch": "noarch"
},
"packages": [{
"arch": "noarch",
"filename": "duck-0.7-1.noarch.rpm",
"name": "duck",
"release": "1",
"sum": ["sha256", "ceb0f0bb58be244393cc565e8ee5ef0ad36884d8ba8eec74542ff47d299a34c1"],
"version": "0.7",
}, {
...
}],
},
{
"name": "coll_name2",
...

}],
...
}
</pre>

h2. Deliverables

* *Sync* should recognize module element in the erratum and save it on the model

* no changes to the model itself are needed (aka migration is not needed) due to changes in the nested structure, inside a pkglist.

* *Publish* should respect the module element and publish info about the module in the errata if this info is available

* see the fixture repo
* publish should continue filtering by rpms being available in the repo
* publish should filter by module being available in the repo
*
if no rpms are found for/associated with an erratum but module information is specified, such erratum has to be published. It's possible that just module metadata changed and no rpms has been updated, e.g an rpm was removed from the @artifacts@ to fix the module issue. updated.
* document that filtering of errata being published is performed according to rpms and modules present in a repo
*
make sure collection names are unique per erratum (Pulp takes care of that and regenerates collection names to make them unique. I think at the moment coll_name = repo_id + idx, the suggestion is to make it, repo_id + module info + idx)

* *Upload* should support the module element

* see the JSON format in the description above

* *Copy*

* simple copy is expected to just work
* copy with --recursive flag should respect the module info in the erratum

* a whole module should be copied in this case: *all* its RPMs, module itself, and relevant module_defaults(?)

* *Search* API

* probably no changes needed, it should just work

Out of scope: *Applicability* (it will be implemented as a separate story).

h3. Note

Mind that the module and rpms listed in the erratum are the fixed ones (the ones present in the repo)

Back