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

[James Antill]

On Tue, 2015-07-14 at 10:01 -0400, Colin Walters wrote:
> 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

 yum/dnf don't either, in this case. If you have 666 versions of zsh
then nothing cares if you install zsh-1 or zsh-666, saying it cares
about versions because "install zsh" chooses 666 instead of the 664 you
wanted is weird phrasing IMO.
 There are cases where it does care a bit, mostly to stop people
accidentally shooting themselves, like if you have version 666 installed
and want to "upgrade" to 664 ... but you don't have those problems
because you start fresh for every build.

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

 On the client side priorities/versionlock are the obvious starting
points. Although they are both plugins. Depending on how easy you need
it to be to change what is/isn't held back then you could use the glob:
statement on yum's exclude (as a simple way to just exclude specific
packages you want to "rollback").

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

 The only things I can think of that allow you not to change mock is if
you could use "repo-pkgs install", having custom repos. with the
packages already removed, or maybe using excludes directly.

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

 Do you mean you aren't aware of any packages you are building with that
use epochs? Or you can't see how the package selection can be different?

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

 install or upgrade doesn't matter, the "depsolve" is different
depending on if you ignore the epoch with the above data.

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

 I mean the easiest thing here is for unship to move the package out of
the repo. ... then everything just works on the ostree build side, and
anyone pointing at it with just yum can also just distro-sync or
whatever. Why do you need/want to keep the packages in the repo. after
an unship?