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 <bkear...@redhat.com
<mailto:bkear...@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
plugin.
> 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@redhat.com <mailto:Pulp-dev@redhat.com>
https://www.redhat.com/mailman/listinfo/pulp-dev
<https://www.redhat.com/mailman/listinfo/pulp-dev>
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
