Bug 1478208 - [rfe] Support for multiple copr instances
[rfe] Support for multiple copr instances
Status: NEW
Product: Fedora
Classification: Fedora
Component: dnf-plugins-core (Show other bugs)
27
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Suchý
Fedora Extras Quality Assurance
: FutureFeature, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-08-03 20:07 EDT by Alois Mahdal
Modified: 2018-01-08 05:24 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alois Mahdal 2017-08-03 20:07:25 EDT
Description of problem
======================

`dnf copr` should be able to work (enable, disable, list...) with
different instances of COPR than copr.fedorainfracloud.org.  User should
be able to add coprs from multiple instances along with copr.f.o.

I have a COPR repo at internal Red Hat instance and I would like to
instruct potential users how to enable it.  AFAIK, all I can do now is
to tell them to drop the .repo file in /etc/yum.repos.d, but I'd have to
give them at least URL which is not the same across Fedora versions/archs.

This would need to establish syntax for specifying the instance.
Just a few quick ideas:

    # dnf copr enable https://copr.foo.example.com/coprs/joe

    # dnf copr add foo https://copr.foo.example.com/coprs/joe
    # dnf copr enable foo:joe
    # dnf copr list foo:joe


Version-Release number of selected component
============================================

dnf-1.1.10-6.fc25.noarch
dnf-plugins-core-0.1.21-5.fc25.noarch
Comment 1 Daniel Mach 2017-08-09 07:12:09 EDT
related to COPR plugin -> reassigning to msuchy
Comment 2 Fedora End Of Life 2017-11-16 14:20:34 EST
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Comment 3 clime 2018-01-08 04:50:04 EST
There is: https://github.com/rpm-software-management/dnf-plugins-core/blob/master/plugins/copr.py#L91

So that should do it if /root/.config/copr is present. Can you confirm?

I think we could remove: 

if self.copr_url != "https://copr.fedorainfracloud.org":
    print(_("Warning: we are using non-standard Copr URL '{}'.").format(self.copr_url))"

but at the same time, some info about /root/.config/copr being read would be useful.

This would be better placed in dnf configuration somewhere.
Comment 4 Pavel Raiskup 2018-01-08 05:24:26 EST
(In reply to clime from comment #3)
> There is:
> https://github.com/rpm-software-management/dnf-plugins-core/blob/master/
> plugins/copr.py#L91
> 
> So that should do it if /root/.config/copr is present. Can you confirm?

It does, it is cumbersome though... see below.

> I think we could remove: 
> 
> if self.copr_url != "https://copr.fedorainfracloud.org":
>     print(_("Warning: we are using non-standard Copr URL
> '{}'.").format(self.copr_url))"

I wouldn't do this.  Users shouldn't ideally touch the ~/.config/copr,
that config file should be related to the "main" copr instance (aka
Fedora's copr production).  If users want to enable something from
different copr instance, it deserves separate configuration file.

> but at the same time, some info about /root/.config/copr being read would be
> useful.

I dislike the fact that dnf and copr-cli share the same configuration
file.  This means that (a) it is a bit harder to keep the api of that
file, and (b) dnf can know some info which is not supposed to be known
by dnf (namely secure copr token).

> This would be better placed in dnf configuration somewhere.

Definitely.  Dnf could have it's own configuration file, say `copr.conf`,
where users could insert e.g. several sections like `[fedora-copr]`
(the default) and `[internal-copr]`.  Then,
`dnf copr --instance internal-copr` could be used.  Well, that's just
idea, the semantics can be different -- but dnf should be able to work
with many copr instances at the same time.

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