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

[James Antill]

On Sat, 2015-07-11 at 16:52 -0400, Colin Walters wrote:
> I'm looking at doing an "Atomic Continuous" build using
> rpmdistro-gitoverlay[1] which pulls down many projects from git,
> auto-builds rpms, and then using rpm-ostree to composes OSTree commits
> from that.  A key feature of this model is the ability to "undo" or
> freeze to an earlier commit, because OSTree doesn't care about version
> numbers - they can go backwards or freeze for a while when things
> inevitably break.
> 
> However, yum does obviously care about versions.

 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.
 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.

>   And rpmdistro-gitoverlay uses mock which uses yum.  Currently
> rpmdistro-gitoverlay injects an Epoch of 99, and to make that work we
> need patches to optionally honor the epoch in internal dependencies. 

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

>   This isn't any uglier than the %{?_isa} stuff I think.

 _isa is just a magic macro that is defined differently per. arch, like
_arch or CHAR_BITS.
 But this is directly altering the EVR of packages? And ignoring all
epoch values in PRCO data? 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

...this should upgrade #1 to #2 when B is installed, but now won't?


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