Bug 1193851 - [RFE] Add support for --repoid parameter
Summary: [RFE] Add support for --repoid parameter
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: rawhide
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-02-18 12:18 UTC by Vít Ondruch
Modified: 2015-09-22 06:51 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-09-22 06:51:40 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Vít Ondruch 2015-02-18 12:18:23 UTC
Description of problem:
YUM's repoquery supports --repoid=somerepo parameter, which replaces the pair --disablerepo=* --enablerepo=somerepo. It would be nice if DNF supports this parameter.


Version-Release number of selected component (if applicable):
$ rpm -q dnf
dnf-0.6.4-1.fc21.noarch


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:
$ dnf repoquery --disablerepo=* --enablerepo=rawhide rubygem-listen
Using metadata from Wed Feb 18 12:49:27 2015
rubygem-listen-0:2.7.11-1.fc22.noarch

$ dnf repoquery --repoid=rawhide rubygem-listen
Using metadata from Wed Feb 18 12:48:25 2015


Expected results:
$ dnf repoquery --disablerepo=* --enablerepo=rawhide rubygem-listen
Using metadata from Wed Feb 18 12:49:27 2015
rubygem-listen-0:2.7.11-1.fc22.noarch

$ dnf repoquery --repoid=rawhide rubygem-listen
Using metadata from Wed Feb 18 12:49:27 2015
rubygem-listen-0:2.7.11-1.fc22.noarch


Additional info:
Please note that I demonstrate the --repoid parameter with repoquery, but it is similarly useful when I want to test updated package, for example this would be much appreciated:

$ sudo dnf update --repoid=updates-testing dnf\*

Comment 1 Radek Holy 2015-02-18 12:27:58 UTC
(In reply to Vít Ondruch from comment #0)
> Additional info:
> Please note that I demonstrate the --repoid parameter with repoquery, but it
> is similarly useful when I want to test updated package, for example this
> would be much appreciated:
> 
> $ sudo dnf update --repoid=updates-testing dnf\*

Hello, thank you for the report.
Please note that there is the "repository-packages" command (http://dnf.readthedocs.org/en/latest/command_ref.html#repository-packages-command) that might be interesting for you. It depends on your use cases. Sometimes the "repository-packages <repo> upgrade" command may be better (because you want the other repositories to be available to satisfy some dependencies) but on the other hand I can see that the "--repoid" switch might be better in another cases. And also the "repository-packages <repo> list" command is not as powerful as "repoquery". Anyway, this is just a nice to have shortcut so the priority is not too high.

Comment 2 Vít Ondruch 2015-02-18 13:42:16 UTC
(In reply to Radek Holy from comment #1)
Thanks for the tip. Was not aware about such command. However

1) It does not disable other repositories, which is quite important, especially for repoquery, since I want to be sure that I am querying the right and the only repository. Typically, on my F21, I am interested just in rawhide packages.

Also in some cases, it might save some time avoiding of metadata download.



2) It does not work with repoquery:

$ LANG=en_US sudo dnf repository-packages rawhide repoquery rubygem-listen
Error: Requires a repo ID and a valid sub-command
 Mini usage:

repository-packages REPO check-update|info|install|list|move-to|reinstall|reinstall-old|remove|remove-or-distro-sync|remove-or-reinstall|upgrade|upgrade-to [ARG...]

Run commands on top of all packages in given repository

aliases: repo-pkgs, repo-packages, repository-pkgs
Error: a repo ID and a valid sub-command required


Is it by design? Shouldn't the functionality be more universal and automatically picked up by plugins? Just asking ...




3) Does it work at all?

$ LANG=en_US sudo dnf repository-packages rawhide info kernel
Using metadata from Wed Feb 18 13:13:55 2015
Error: No matching Packages to list

Comment 3 Radek Holy 2015-02-18 14:01:08 UTC
1) Definitely. I agree with you. I reacted mostly to the last paragraph (see the citation).

2) Yes, "repo-pkgs" is a command, not a switch. It's not possible to combine builtin commands with plugin commands. Some cases may be covered by "dnf repo-pkgs <repo> list <spec>".

3) It does but you need to enable the repository. Unlike YUM, DNF does not enable the repository for you. Please run "sudo dnf --enablerepo=rawhide repository-packages rawhide info kernel". It is expected but I admit that it's inconvenient and debatable.

Comment 4 Vít Ondruch 2015-02-18 14:32:30 UTC
(In reply to Radek Holy from comment #3)
Actually, it makes sense after explanation although it could be recorded in the documentation ;) Thx for explanation and looking forward for --repoid param.

Comment 5 Honza Silhan 2015-07-20 14:18:03 UTC
Hi, the `repoid` option  is implemented in repoquery (has been renamed to `repo`). If it donsn;t fit your expectations, feel free to reopen.

Comment 6 Vít Ondruch 2015-07-20 14:44:02 UTC
(In reply to Jan Silhan from comment #5)
> has been renamed to `repo`

That is probably better name. Looking forward to shorten my cmdlines ;) Thanks.

Comment 7 Vít Ondruch 2015-07-27 15:06:40 UTC
# dnf repoquery --disablerepo=* --enablerepo=rawhide-source --arch=src --whatrequires prelink
langpacks: No languages are enabled
Last metadata expiration check performed 0:07:16 ago on Mon Jul 27 16:58:15 2015.
aide-0:0.15.1-10.fc23.src
anyterm-0:1.1.29-27.fc23.src
elpa-0:2015.02.002-5.fc23.src
gnu-smalltalk-0:3.2.5-9.fc23.src
gromacs-0:5.0.5-3.fc23.src
hugs98-0:2006.09-22.fc23.src
lightning-0:2.1.0-3.fc23.src
openblas-0:0.2.14-3.fc23.src
skychart-0:3.10-6.fc23.src
transgui-0:5.0.1-4.fc23.src
wine-0:1.7.47-1.fc23.src
zfs-fuse-0:0.7.0-21.fc23.src


# dnf repoquery --repo=rawhide-source --arch=src --whatrequires prelink
usage: dnf [--allowerasing] [-b] [-C] [-c [config file]] [-d [debug level]]
           [--debugsolver] [--showduplicates] [-e ERRORLEVEL]
           [--rpmverbosity [debug level name]] [-q] [-v] [-y] [--assumeno]
           [--version] [--installroot [path]] [--enablerepo [repo]]
           [--disablerepo [repo]] [-x [package]] [--disableexcludes [repo]]
           [--repofrompath [repo,path]] [--noplugins] [--nogpgcheck]
           [--disableplugin [plugin]] [--color COLOR]
           [--releasever RELEASEVER] [--setopt SETOPTS] [--refresh] [-4] [-6]
           [-h]
Command line error: argument --repofrompath: bad format: rawhide-source


$ rpm -q dnf
dnf-1.0.2-2.fc22.noarch


IOW, it does not work.

Comment 8 Radek Holy 2015-07-27 15:14:09 UTC
Well, it did work until the --repofrompath option was introduced (dnf-1.0.2-1). This is a new bug.

Comment 9 Vít Ondruch 2015-07-27 15:16:55 UTC
ok :) ... btw the --repo parameter is not mentioned in the "usage" output, not sure if that is just side effect or some other issue.

Comment 10 Honza Silhan 2015-07-27 16:19:59 UTC
Vit, `--repo` is param of repoquery, although it makes sense to be DNF global param. We could move it.

Comment 11 Vít Ondruch 2015-07-28 05:26:46 UTC
(In reply to Jan Silhan from comment #10)
Ah, did not noticed these are just the global parameters. Then I have two remarks:

1) Since enablerepo/disablerepo/repofrompath are global parameters, this would definitely make sense to make repo option global as well.

2) It would be nice to output the "command" options as well as global options.

Please let me know if I should report some of these two into separate ticket. Thx.

Comment 12 Vít Ondruch 2015-08-05 10:49:37 UTC
Now I learned about "repository-packages" command. It seems that the "--repo" parameter is doing more or less the same. Could you please explain the difference?

TBH, I am really horrified by the "repository-packages" since it seems it duplicates all the basic command in totally non-systematic way. It would be nice if you can deprecate it prior somebody starts to use it.

Comment 14 Radek Holy 2015-09-22 06:51:40 UTC
We have got a separate report of this problem. Let's track it there [1] and let's close this as it was.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1260986


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