When I build an rpm package with the same name as a package that already exists in a repo and type the command

$ dnf info package

This command only shows information about the built package. I would like to be able to run above command and dnf builddep package, and be able to choose which package I get information from.

Is there a way to differentiate between repo and self built packages without giving them different names?

Addendum: Built packages have newer versions


Look at the lines Repo and From repo in the dnf info output. These will tell you:

  • Repo tells you the repository that an available package is in. If the package is installed then it will tell you @System.
  • From repo appears only for installed packages. It gives the repository from which an installed package originated. It shows a repo name (e.g. fedora or updates) or @commandline for a manually installed RPM.

dnf builddep will install build dependencies for the latest version of the named package in the repositories. It doesn't do anything with manually installed RPMs.

| improve this answer | |
  • Ahh I see now, but how would I differentiate packages when using dnf builddep package? If I have two packages with the same name, will it not just return results for one of them only? – MyWrathAcademia Jul 19 '18 at 19:43
  • @MyWrathAcademia If you've got two packages with the same name, they should be the same software (even if different versions). – Michael Hampton Jul 19 '18 at 19:50
  • @MyWrathAcademia And in any case, if you're rebuilding source RPMs and not using mock then you're doing it wrong. – Michael Hampton Jul 19 '18 at 20:00
  • I don't get @commandline for a package I installed using rpm -ivh. However, the rest is correct. I am using fpm, what can mock do that makes it necessary when building source RPM's? – MyWrathAcademia Jul 21 '18 at 19:08
  • If you're installing deps in order to build a package, the spec file should be the source of the deps anyway. dnf builddep package.spec — problem solved, no ambiguity. (Otherwise, it'll select a package to pull the deps from the same way it selects a package to install. You can have two packages with the same name in two different repos, as well. Of course, if two packages have the same name and version identifiers, why wouldn't they have the same build deps? – FeRD Jun 30 '19 at 0:30

If you want to use dnf builddep to install the deps of a specific package, simply be more specific. In other words, you can do all of the following:

$ sudo dnf builddep somepackage-1.2.3
$ sudo dnf builddep somepackage-1.2.3-9.fc30
$ sudo dnf builddep /path/to/some/uninstalled/somepackage-1.2.4-1.fc30.$arch.rpm
$ sudo dnf builddep /path/to/some/unbuilt/somepackage-1.2.4-2.fc30.srpm
$ sudo dnf builddep /path/to/some/unbuilt/somepackage.spec

Ditto with dnf info, for the first two. (You can't run dnf info on a file path to an RPM, SRPM, or spec, somewhat surprisingly. You can do rpm -q -i -p /path/to/uninstalled.{rpm,srpm} — just have to remember to include the -p flag — but there's nothing similar with dnf info.)

The only time you can't be completely specific about a package's source is when there are packages in two different repos, which have literally the exact same NVR.

Like, say I dnf download --source'd an SRPM for a package in the Fedora updates repo, built local RPMs with rpmbuild -rb, then added them to the local repo I maintain for my own packages. By default, that'll be somepackage-1.2.5-1.fc30.x86_64.rpm or whatever, exactly the same as the one in the updates repo.

Because of that ambiguity, my $HOME/.rpmmacros contains the following:

%dist           .ferd%{fedora}

That ensures the version I build locally comes out as somepackage-1.2.5-1.ferd30.x86_64.rpm, instead of .fc30, so I can differentiate.

| improve this answer | |

Your Answer

