On 06/23/2016 03:14 AM, Javier Pena wrote:
Hi all,
RDO Trunk repos are meant to package the latest upstream commits, but in some rare cases
we may need to pin a specific package to a non-latest commit to temporarily fix a
breakage.
This week, we had one of those cases with keystonemiddleware, but the procedure used to
do it caused some disruption because some commits were rebuilt, breaking the
current-passed-ci and current-tripleo repos for centos-master.
Looking for alternatives, my first idea was the following:
- Temporarily take that package out of rdoinfo using a specific tag (e.g. tag: to-fix)
- And add a working package to an "overrides" repo, included as part of
delorean-deps.repo
One potential issue here is that most (all?) consumers of dlrn use
yum-plugin-priorities to make sure all packages in main dlrn repo take
precedence over dlrn deps repo regardless of NVR. Will removing a
package from rdoinfo make it disappear from future repos?
Also, how do we signal to the various external consumers of dlrn which
packages we have pinned and why?
This avoids any DLRN db hacks, but stops processing updates for the package until the
breakage is fixed.
What do you think? Any alternative ideas?
One alternative is to maintain a list of packages we use only from
release tags. The root issue being that those projects do not strive to
maintain master in working order, and in fact upstream CI is using
releases to test them.
I think the individual pinning solution is simpler if we only have a few
issues per cycle, but the package list solution is better if it happens
often enough that the pinning/unpinning becomes burdensome.
Maybe we should go with the pinning solution for a cycle and re-evaluate
(assuming couple minor issues above are resolvable).
Thanks,
Javier
_______________________________________________
rdo-list mailing list
rdo-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
To unsubscribe: rdo-list-unsubscribe(a)redhat.com