[Rpm-ecosystem] Fedora dist-git patches to allow using rpmdistro-gitoverlay to build the stack for CentOS7

Colin Walters walters at verbum.org
Tue Jul 14 14:01:56 UTC 2015


On Tue, Jul 14, 2015, at 12:52 AM, James Antill wrote:

>  I'm not sure what you are saying here, in this context (installing a
> group of packages to specific versions) I don't believe
> yum/rpm/dnf/libhif cares about versions more than ostree itself does.

ostree doesn't care about versions, rpm-ostree does of course by default.

>  It needs to work out what it should install, and a specification of
> "foo" is usually taken to mean "foo-<latest>" but that doesn't mean it
> cares what any of the numbers are. If you want to hold certain versions
> of packages back there are a number of ways of doing that, at least on
> the yum side.

Can you be more specific?  I know there's the priorities plugin...which
I'm now looking at more closely.

The reason I had shied away from this a bit is that I had wanted to
avoid requiring changes to mock.

>  This seems like one of the most hacky/ugly though[1].

Possibly, but I'd need to compare it to specific alternatives.

> How does that work if epoch is used in the
> package? Eg.
> 
> #1 A-0:4-1.noarch 
> #2 A-1:2-1.noarch
> 
> B: Conflicts: A < 1:2

I think offhand for buildroots that shouldn't matter - I can't think
of a case where it would cause a different package set
selection (but I may not be trying hard enough).

For in place upgrades if using yum/dnf to *consume* the RPMs,
it might be an issue.  rpm-ostree always makes trees fresh,
so whatever result of the depsolve is a server side choice and
not subject to past history per-client.  

> [1] Maybe I'm just really confused about what you are doing?

I'm not explaining it very well I know - but the basic goal
here is something like COPR, except with the ability to
"unship" - if I specify an earlier git commit after testing
determines it's broken, that earlier (lower) version number
should be used in both buildroots and appear on the client.

Anyways I'm looking at the priorities plugin now, and
I may be able to get this to work well for my use case.



More information about the Rpm-ecosystem mailing list