<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 05/15/2018 10:41 AM, Jeff Ortel
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:d371b951-497f-ca00-0e8c-cf6167366ed4@redhat.com">
<br>
<br>
On 05/15/2018 10:27 AM, Bryan Kearney wrote:
<br>
<blockquote type="cite">On 05/14/2018 03:44 PM, Jeff Ortel wrote:
<br>
<blockquote type="cite">Let's brainstorm on something.
<br>
<br>
Pulp needs to deal with remote repositories that are composed
of
<br>
multiple content types which may span the domain of a single
plugin.
<br>
Here are a few examples. Some Red Hat RPM repositories are
composed of:
<br>
RPMs, DRPMs, , ISOs and Kickstart Trees. Some OSTree
repositories are
<br>
composed of OSTrees & Kickstart Trees. This raises a
question:
<br>
<br>
How can pulp3 best support syncing with remote repositories
that are
<br>
composed of multiple (unrelated) content types in a way that
doesn't
<br>
result in plugins duplicating support for content types?
<br>
<br>
</blockquote>
<br>
Both these examples are cases of RPM repos, yes? If so, does
this
<br>
require a general purpose solution?
<br>
</blockquote>
<br>
The example in the thread is mainly RPM but there are other
repositories with shared content types. Eg: OSTree repositories
also containing Kickstart Trees.
<br>
</blockquote>
<br>
I also think there is value in not having the RPM plugin be a <i>mega</i>
plugin that knows how to deal with several complicated types of
content (like in pulp2). Making each plugin responsible for
specific closely related types of content would make them more
maintainable.<br>
<br>
<blockquote type="cite"
cite="mid:d371b951-497f-ca00-0e8c-cf6167366ed4@redhat.com">
<br>
<blockquote type="cite">
<br>
-- bk
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>