Bug 1340900 - [RFE] option to prefer packages from repos
Summary: [RFE] option to prefer packages from repos
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Copr
Classification: Community
Component: backend
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: clime
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-30 15:36 UTC by Igor Gnatenko
Modified: 2017-06-29 08:22 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-29 08:22:23 UTC


Attachments (Terms of Use)

Description Igor Gnatenko 2016-05-30 15:36:18 UTC
As COPR is trying to be a place for CI there is one problem. It always prefer packages from Fedora repos.

Let's imagine that we have dnf-1.1.9-1 in Fedora repos.

Steps to reproduce:
1. We build dnf-1.1.8-9 in COPR repo
2. We build dnf-plugins-core-0.1.21-1 in the same COPR repo

Actual results:
dnf-plugins-core built with dnf-1.1.9-1 from Fedora repos.

Comment 1 Miroslav Suchý 2016-05-30 16:16:28 UTC
What is the use-case for need of older package that is in Fedora repos? I.e. why are you building older package in that repo? Just curious.

Comment 2 Igor Gnatenko 2016-06-16 12:46:19 UTC
(In reply to Miroslav Suchý from comment #1)
> What is the use-case for need of older package that is in Fedora repos? I.e.
> why are you building older package in that repo? Just curious.

because I want to bisect something? it's not only about DNF.

Currently fakechroot is totally broken with RPM testsuite and it was working few years ago, so I need to bisect it. So I'm building older version of chroot and want to build RPM's rpm with exactly that old chroot

Comment 3 Miroslav Suchý 2016-06-16 13:03:51 UTC
This will complicate interface. So I really hesitate to implement.
However this will be possible with "custom chroots" which we plan to implement in very near future.

Comment 4 Igor Gnatenko 2016-06-16 13:09:21 UTC
(In reply to Miroslav Suchý from comment #3)
> This will complicate interface. So I really hesitate to implement.
> However this will be possible with "custom chroots" which we plan to
> implement in very near future.

What will complicate interface? Checkbox "Prefer packages from COPR repository over official"? Like it is done for "Disable network"..

Comment 5 clime 2016-10-07 06:59:57 UTC
(In reply to Igor Gnatenko from comment #0)
> As COPR is trying to be a place for CI there is one problem. It always
> prefer packages from Fedora repos.
> 
> Let's imagine that we have dnf-1.1.9-1 in Fedora repos.
> 
> Steps to reproduce:
> 1. We build dnf-1.1.8-9 in COPR repo
> 2. We build dnf-plugins-core-0.1.21-1 in the same COPR repo
> 
> Actual results:
> dnf-plugins-core built with dnf-1.1.9-1 from Fedora repos.

So the problem here is that the dnf version in Fedora is newer than in the COPR repository, right? Preferring the latest version is a natural behavior. What we could do is to add some kind of package overriding. Let me know if you have an idea.

Comment 6 Igor Gnatenko 2016-10-07 07:04:22 UTC
(In reply to clime from comment #5)
> So the problem here is that the dnf version in Fedora is newer than in the
> COPR repository, right?
yes
> What we could do is to add some kind of package overriding. Let me know if
> you have an idea.
No idea, honestly. But for our testing purpose it's something must have.

Comment 7 Miroslav Suchý 2016-10-07 09:36:48 UTC
See
  man dnf.conf

       priority
              integer

              The priority value of this repository, default is 99. If there is more than one candidate package for a particular operation, the  one
              from  a  repo  with  the lowest priority value is picked, possibly despite being less convenient otherwise (e.g. by being a lower ver‐
              sion).


So we can add something to Settings->Chroot->Edit which will change the priority of this repo.
However passing it to mock config, will be pain.

Comment 8 clime 2017-06-29 08:22:23 UTC
I am not really getting this issue. Always the highest version is used, which means it makes sense what happened in the original issue description. Feel free to reopen.


Note You need to log in before you can comment on or make changes to this bug.