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