[Rdo-list] Why use yum priority in rdo-release repo file?

[Sandro "red" Mathys]

On Thu, Jun 20, 2013 at 5:01 PM, Matthias Runge <mrunge at redhat.com> wrote:

> On 20/06/13 14:15, Sandro "red" Mathys wrote:
> > On Thu, Jun 20, 2013 at 1:56 PM, Matthias Runge <mrunge at redhat.com
> > <mailto:mrunge at redhat.com>> wrote:
> >
> >     On 20/06/13 13:50, Sandro "red" Mathys wrote:
> >     > Great, thanks for the quick reply and the quick fix. Still thinking
> >     > yum priorities are bad and should be removed completely from RDO
> >     > (RHOS is a different story) but if only directly openstack related
> >     > packages remain in the repo, it shouldn't matter anyway. -- Sandro
> >     >
> >     Why do you think priorities are bad?
> >
> >
> > Because they are patronizing the user, relatively hard to overcome and
> > situations where they seem necessary should be avoided in general.
> >
> Yum does not resolve dependencies very well, when it comes to ambiguities.
>

True. If there are ambiguities which is to be avoided (as said before).


> Simple example: we're using Django14 in RDO, whereas EPEL has both, and
> the same versions.
>
> yum prioritizes packages with shorter names, thus would install Django
> instead of Django14. (version 1.3 vs. 1.4).
>

Yum itself does not prioritize anything based on package names. If you
install django, it will install django. If you install django14, it will
install django14. Doesn't matter to yum whether django is 1.3, 1.4 or 1.5
in either case.

...unless you Require django and hope django14 does Provide django and that
that's good enough. It isn't. Requiring something like django >= 1.4 should
be in that case, though.

Other example: You could have a version of a software which is just a
> plain "community" version, whereas you could have in RDO a more
> "supported" version, e.g expressed by other logos etc, but still the
> same package version.
>

You could do a lot of things, but lets stick to actual use cases. Even if
you change the logo, openstack-horizon in RDO should still be newer than
the one in EPEL.


> >
> > Like in what case? When will RDO ever want an older version of something
> > than what is in RHEL / EPEL?
>
> Good question: what will be priorized? Higher prio repo or higher
> package version?
>

Well, that's the point of y-p-p: only the higher repo prio counts. Like the
case I mentioned before. RDO had Puppet 2.6 and puppetlabs Puppet 3.2.
Puppet from RDO, having a higher repo prio than default, would always win.


> > The only thing I can possibly come up with right now are the kernel and
> > other tools where new networking stuff (netns, maybe more) was enabled
> > ahead of time but I sure hope those changes make it back into RHEL with
> > the next kernel update there. Or if not, that new RHEL kernels are again
> > re-built with those patches for RDO as well to avoid security holes.
>
> Good to see, you have found a use-case.
>

And I also explained why the use case must be discarded.

-- Sandro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20130620/5b2d459e/attachment.html>