[Pulp-dev] Composed Repositories
jortel at redhat.com
Wed May 16 15:04:50 UTC 2018
On 05/15/2018 11:59 AM, Brian Bouterse wrote:
> I agree these are specific cases for a few content types that are used
> by multiple plugins. I think the most productive thing would be for us
> to talk in specific only about kickstart trees being shared between
> RPM and ostree. It would be much easier to generalize after building
> something specific once (I think).
This discussion wasn't about generalization or abstraction. It's about
dealing with remote repositories that are different combinations of
common content types. That said, while searching for concrete examples
(use cases), it turns out these combinations don't really exist. In
pulp2, the RPM plugin is used to sync ISO repositories but they are not
combined with other content types in the same repository. Kickstart
trees are only combined with YUM repositories. Combination
OSTree/KS-tree repositories aren't really a thing.
I think this thread can end here.
> A mentor I had once told all software that lives long enough goes
> through 3 phases. (1) A concrete implementation (2) generalizing that
> implementation, and then (3) rewriting that implementation because of
> everything you didn't know before. I'm advocating for us to think
> about the problem as a specific plugin problem (step 1) and then after
> that is done, to look at generalizing it (step 2).
> On Tue, May 15, 2018 at 11:27 AM, Bryan Kearney <bkearney at redhat.com
> <mailto:bkearney at redhat.com>> wrote:
> On 05/14/2018 03:44 PM, Jeff Ortel wrote:
> > Let's brainstorm on something.
> > Pulp needs to deal with remote repositories that are composed of
> > multiple content types which may span the domain of a single
> > Here are a few examples. Some Red Hat RPM repositories are
> composed of:
> > RPMs, DRPMs, , ISOs and Kickstart Trees. Some OSTree
> repositories are
> > composed of OSTrees & Kickstart Trees. This raises a question:
> > How can pulp3 best support syncing with remote repositories that are
> > composed of multiple (unrelated) content types in a way that doesn't
> > result in plugins duplicating support for content types?
> Both these examples are cases of RPM repos, yes? If so, does this
> require a general purpose solution?
> -- bk
> Pulp-dev mailing list
> Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev