Hey! I've been working on hoisting the Distributed Publication feature to pulpcore (pulp/pulpcore#7514). This was motivated by RPM requiring a solution to the same problem.
First of all I wanna hear some feedback or concerns about the initiative.
Then discuss superseeding plan, if that's ok.
Superseeding plan
I have an implementation in place with basically the same approach as the one in place here, except it handles pass-through cases (e.g, pulp_file). In pass through publications, no published artifact is involved and ContentArtifacts are matched directly.
The feature adds a core model with the same name, but with some care taken to avoid name collisions. As it's internal, we don't need to worry with API collisions. Because the content handler calls pulp_deb's content_handler customization, deb will keep using it's own implementation if no action is taken.
Given that, here are some options I could think of for superseeding:
Let $v_0$ be the pulpcore version where the feature is released.
- When deb bumps the bump pulpcore lowerbound to $>=v_0$, deb's implementation gets removed.
- Until then, deb will use it's own implementation
- The system will have doubled DistributedPublication objects. Pulpcore one will be ignored
- Very low effort
- Right now, add conditional to the code to use core's implementation if available. Then finalize with (2)
- Deb uses core implementation right away, when possible
- We might skip deb's DistributedPublication creation if core's implementation is detected (no duplicates).
- Medium effort
Hey! I've been working on hoisting the Distributed Publication feature to pulpcore (pulp/pulpcore#7514). This was motivated by RPM requiring a solution to the same problem.
First of all I wanna hear some feedback or concerns about the initiative.
Then discuss superseeding plan, if that's ok.
Superseeding plan
I have an implementation in place with basically the same approach as the one in place here, except it handles pass-through cases (e.g, pulp_file). In pass through publications, no published artifact is involved and ContentArtifacts are matched directly.
The feature adds a core model with the same name, but with some care taken to avoid name collisions. As it's internal, we don't need to worry with API collisions. Because the content handler calls pulp_deb's content_handler customization, deb will keep using it's own implementation if no action is taken.
Given that, here are some options I could think of for superseeding:
Let$v_0$ be the pulpcore version where the feature is released.