Hi,
I'm mostly replying to Sreyan's questions, hopefully adding
to what you've said (much) more succinctly than I, Samuel.
I may have taken a few tangents along the way.
Samuel Sieb wrote:
> On 7/29/20 2:57 PM, Sreyan Chakravarty wrote:
>> I tried:
>> $ dnf repoquery --installed kernel*-5.6.*
>> kernel-0:5.6.10-300.fc32.x86_64
>>
>> Where is the extra 0 in " kernel-0 " coming from ? If you see the rpm
>> -qa output the zero is not present there:
>
> That seems like an odd command, but that "0:" is the epoch (0 is also no
> epoch). That command includes the epoch in the listing.
It is why I mentioned the --nvr option to repoquery too,
knowing that the default format of the output from `dnf
repoquery` differs from `rpm -q`. :)
And yes, many long-time users (myself included) generally
prefer to use the rpm command directly for querying the
local rpm database, at least in the case of simple package
listings. Things like `rpm -qa --last` are very handy, and
easier to use than the `dnf history` commands (for me,
anyway).
There are are good uses for `dnf repoquery` too -- even for
local package queries. Particularly when you want to list
the repository from which a package was installed.
>> $ rpm -qa | grep ^kernel | grep '5\.6'
>>
>> kernel-5.6.8-200.fc31.x86_64
>
> rpm by default does not include the epoch info. It's rarely relevant.
Until it is, of course. ;)
That's when you end up wondering why something isn't
updating because you can see that 1.0 is less than 2.0, yet
dnf installs the 1.0 version.
The way NEVRA is listed is still generally jarring to view
though. And I do agree that it's not relevant in the vast
majority of cases.
(It'll probably be even less so over time, since Fedora
started doing a distro-sync for system upgrades a few
releases or so ago. That means epoch's don't have to live
in a package forever just because they were set ages ago.)
>> How do I know which is the epoch and the version and the release in
>> NEVRA ? And are there any standard separators between them ?
>>
>> kernel-5.6.10-300.fc32.x86_64
>>
>> Which is what here ? I know the name is 'kernel' that one was easy. :-)
The fields are separated by a '-' character (except for the
oddball of '%{ARCH}' at the end, which uses a '.' as the
separator).
If you want to parse the fields from a package name on your
own, you split it from right to left, since the package name
may contain a '-' character. (If you're writing scripts to
do that, it's probably better to use a library for it. In
the past, the yum code included an rpmUtils python module,
which included a splitFilename() method¹. I'm not sure
offhand what the recommended replacement for that is. It's
not a task I need to perform from a script with any
frequency.)
¹ https://github.com/rpm-software-management/yum/blob/f8616a2d6/rpmUtils/miscutils.py#L301
>> Thanks for your help. I want to use DNF wherever I can since it is the
>> more standard way to do package queries.
>
> rpm is probably faster, but can only give you information about what is
> currently installed on your computer. dnf can look through all the
> repository files to get you info on anything that's available.
Indeed. I think it's preferable to use whichever tool is
best suited to the task. It's sometimes convenient to use
dnf for local queries, but it's very unlikely to ever be as
quick as rpm for those tasks. (I chuckled at the very
generously-worded "rpm is probably faster" part of that
sentence Samuel. :)
And often, trying to use dnf requires more effort than it
would to do the same thing in rpm, like the example of
querying the locally installed kernel rpm's from this
thread. (Of course, if the goal is only to remove the
packages, then there's no need to query them, get a list,
then feed it to dnf at all.)
While I'd say it's probably best to use dnf for installing
and removing packages rather than using rpm for that task,
even that's just a general guideline.
There's nothing wrong with using rpm to install or update a
package. However, doing so does stop dnf from:
* recording the origin repository of the package
* allowing dnf history to undo an install
* preventing you from removing critical packages
(among various other niceties).
Whether or not any of those reasons are important or not is
a matter of personal preference for the most part. It's
always good to know when a guideline is worth ignoring. :)
--
Todd
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
