Add pulpcore, pulpcore-plugin, and pulp_file to Fedora 30
1. make the 3 spec files using pyp2rpm
2. Submit them to Fedora https://docs.fedoraproject.org/en-US/quick-docs/creating-rpm-packages/index.html
This would be for pulp_file specifically and pulpcore and pulpcore-plugin as dependencies of pulp_file.
#5 Updated by firstname.lastname@example.org about 2 years ago
Notes from the Pulp team meeting on this:
Agreed at PulpCon not to build RPMs and have QE test them as officially supported method of Pulp 3 delivery. Did not have urgent internal driver & didn't want to spend time testing what we thought would be required ahead of knowing what katello or Ansible Galaxy stakeholders required just due to past requirements.
- Pulp 2 dropped in fedora dropped (QE & dev more time to focus on current priorities)
- f30 dropped mongo dependency, Pulp 2 dropped ahead of this
- Pulp 3 internal ci running on f29 now
- QE main goal - testing for stakeholders with urgent/near term needs
- source install is what is currently tested
- PyPI - main focus for now - it can be added to our CI - easily out of sync
- pulp smash functional & unit tests run during publish process before pushing new asset to PyPI
- Galaxy - reuse PyPI and repackage into containers
- Katello want containers
- Install from source is current QE testing
- dev goal - CI
- stay platform agnostic
Has it's own build process
- Can lag behind
This is unofficial upstream Pulp/downstream Fedora
- how do we communicate availability
- db migrations
- Does ansible scripts handle upgrade?
- Packaging the several dependencies of Pulp3 in Fedora before packaging Pulp & the specified plugins
- Figuring out any scriptlets for upgrades, including Ansible
- Trying to get it done in time for the Fedora 30 release schedule
RPMs are still not an officially supported upstream deliverable. No ask of upstream Pulp to officially support or test them.
RPM specific issues will be likewise not be prioritized. Pulp Developers (Mike) will spend time on this because it does drive engaged user uptake which will provide more feedback to improve quality.
#6 Updated by email@example.com about 2 years ago
We just held another meeting (myself, bmbouter, asmacdo, pcreech & kersom).
We agreed that:
1. My work on the Summit prep will continue to be higher priority than this.
2. I will reach out to Neal Gompa soon to see if the RPM packaging is what he wants; particularly with respect to #3.
3. I will continue to adapt ansible-pulp for the RPM scenario (currently it has the PyPI & source install scenarios.)
4. It will not be that much work to do #3.
5. Creating an RPM like "pulp" with fixed RPM scriptlet logic is not a huge amount of work, but undesirable because of duplicate effort and the fact that it is non-configurable, where as ansible-pulp is configurable. (Although Debian packages with debconf could be configurable.)
Not addressed in the meeting due to lack of time is the upgrade scenario. That is not addressed yet with ansible-pulp & PyPI / source installs yet either.
Please register to edit this issue