Clean up our distribution packaging by moving it to a dedicated repository and building with copr
Our distribution packaging files are spread across all our repositories. This is painful.
This task tracks the effort to move everything packaging-related into `pulp/packaging` on GitHub.
rename pulp-devel to pulp-dev, bring in EVR and copr support
This is a megatrash commit, a snapshot of the work I've done.
Once this is reviewed and merged (and I see what's left...), I'll
put together redmine tasks tracking the remaining work for "complete"
#6 Updated by semyers about 3 years ago
Moving the pulp 2.10 release back a week meant it made sense to prioritize #2086 before this. I haven't spent significant time on this since Friday, but at this point the only thing that's still not working right is setting the python setup.py versions correctly based on the release config and pushing the tag prior building the SRPMs. I should have that fixed up later today for some test builds of 2.10 releases.
#7 Updated by semyers about 3 years ago
I was able to run a 2.10 build in copr today using the new scripts, and get a working pulp install using just the copr repo in fedora 24. The 'kobo' package was not installed despite being listed in the spec file, indicating the packaging repo likely needs an update for pulp 2.10 specs. Once that's taken care of, pulp 2.10 installs from should be working fine.
#8 Updated by semyers about 3 years ago
- Subject changed from Clean up our distribution packaging by moving it to a dedicated repository to Clean up our distribution packaging by moving it to a dedicated repository and building with copr
- Sprint/Milestone deleted (
Updated the subject to match what I'm actually doing with this ticket. Moving the spec files into a dedicated repo per-dist is inexorable from the effort to build pulp in copr, and the effort to build in copr is stalled.
Stuff that's we can do with the new packaging scripts:
- pull down sources and build SRPMs
- tag both the source repo and spec repo with the modified sources (modified to change the version strings)
- build those SRPMs in corp or a local mock root
- being able to tag the specfile repo separately from the source repos means we finally have a way to see exactly what plugins were released for a given version of pulp in a distribution: Just look at the spec files for the tagged version.
It's subtle, but a result of this effort is that anyone with a copr can build pulp packages. Since anyone can get access to copr, this means that anyone can build pulp packages (woot).
Stuff that doesn't work:
- The packages. :( I did a test install of our copr build in fedora23, and while all the normal services (http apps, plus workers) started and appeared to log success, aiming pulp-smash at the install revealed a lot of failures. This was late in the release process for 2.10.0, so rather than dig into those failures at all, I made the decision to effectively give up and began building 2.10 using the "old" process.
- copr appears to support comps.xml, but doesn't include it when generating repodata. This isn't really a problem since we're looking to get rid of comps (#1515), and the docs for 2.10 have indeed been updated to list packages explicitly and not use package groups (at least for platform).
- on-demand repodata generation in copr doesn't work, but really should. It automatically regenerates repodata after every build successfully, but we don't want this for "stable" releases. Rather, we want to ensure all packages build successfully before regenerating repo metadata so that users get all package updates in a single atomic repo update. copr supports this, but the functionality appears to simply be broken.
I'm leaving this assigned to me, as I'll continue to tinker with this, but I'm pulling it off of this sprint. A discussion among the team leads confirms that while we do want to do this, it can (and perhaps should, in hindsight) wait for pulp 3.
#9 Updated by semyers about 3 years ago
- Tags Pulp 3 added
The bulk of the copr work is being broken out into separate tasks. This one, as written, is probably done, since we do indeed have a packaging repo with spec files in it for pulp, its plugins, and its deps. I'd still like to clean up my devel branch related to this, which adds a lot of copr workflow bits that we'll want, so I think I'll call this done once that branch gets merged.
#13 Updated by semyers about 3 years ago
- Status changed from ASSIGNED to CLOSED - CURRENTRELEASE
- Platform Release set to master
Apologies for not moving this to POST:
The devel repo isn't yet known to redmine, but the referenced PR is included on 3.0-dev in that repo:
Since there's also no release structure for the devel repo, I couldn't come up with a better resolution than closing the ticket against the "master" target release.
Please register to edit this issue