package manager for RHEL?

[Olaf Zaplinski]

Hi,

which package manager would you recommend for a RHEL5 system? rpm alone
is unusable, it even cannot erase packages:

# rpm -q audit-libs
audit-libs_1.3.1-1.el5.x86_64
audit-libs_1.3.1-1.el5.i386

# rpm -e audit-libs_1.3.1-1.el5.i386
error: package audit-libs_1.3.1-1.el5.i386 is not installed

Olaf

[Mohd Irwan Jamaluddin]

Post by Olaf Zaplinski
Hi,
which package manager would you recommend for a RHEL5 system? rpm alone
# rpm -q audit-libs
audit-libs_1.3.1-1.el5.x86_64
audit-libs_1.3.1-1.el5.i386
# rpm -e audit-libs_1.3.1-1.el5.i386
error: package audit-libs_1.3.1-1.el5.i386 is not installed

Try this,
rpm -qa | grep audit-libs | xargs rpm -e --allmatches

[Olaf Zaplinski]

Post by Mohd Irwan Jamaluddin
Try this,
rpm -qa | grep audit-libs | xargs rpm -e --allmatches

It does not work:

# rpm -qa | grep audit-libs | xargs rpm -e --allmatches
error: package audit-libs_1.3.1-1.el5.i386 is not installed
error: package audit-libs_1.3.1-1.el5.x86_64 is not installed


Perhaps because of a bash alias?

alias rpm='rpm --qf '\''%{name}_%{version}-%{release}.%{arch}\n'\'''


I had to install this because RHEL5 has a big bug: when you run rpm
directly, it produces this funny output:

# rpm -q audit-libs
audit-libs-1.3.1-1.el5
audit-libs-1.3.1-1.el5

With alias, I get at least:

# rpm -q audit-libs
audit-libs_1.3.1-1.el5.x86_64
audit-libs_1.3.1-1.el5.i386

RHEL4 has no problem like this.

Olaf

[Jos Vos]

Post by Olaf Zaplinski
# rpm -qa | grep audit-libs | xargs rpm -e --allmatches
error: package audit-libs_1.3.1-1.el5.i386 is not installed
error: package audit-libs_1.3.1-1.el5.x86_64 is not installed
Perhaps because of a bash alias?
alias rpm='rpm --qf '\''%{name}_%{version}-%{release}.%{arch}\n'\'''

Yes, make it:

alias rpm='rpm --qf '\''%{name}-%{version}-%{release}.%{arch}\n'\'''

This is just wrong (the underscore).

Post by Olaf Zaplinski
I had to install this because RHEL5 has a big bug: when you run rpm
# rpm -q audit-libs
audit-libs-1.3.1-1.el5
audit-libs-1.3.1-1.el5

This is perfectly ok. It just does not list the architecture,
as rpm never did, and it is not implemented because of backwards
compatibility reasons.

Post by Olaf Zaplinski
RHEL4 has no problem like this.

RHEL4 behaves exactly the same, but you might not have
installed two architectures of that package.

[Olaf Zaplinski]

Post by Jos Vos
RHEL4 behaves exactly the same, but you might not have
installed two architectures of that package.

In fact, this new system seems to be a mix of x86_64 and i386 packages,
and now I am 'cleaning' it.

Olaf

[Jeff Johnson]

Post by Jos Vos

Post by Olaf Zaplinski
# rpm -qa | grep audit-libs | xargs rpm -e --allmatches
error: package audit-libs_1.3.1-1.el5.i386 is not installed
error: package audit-libs_1.3.1-1.el5.x86_64 is not installed
Perhaps because of a bash alias?
alias rpm='rpm --qf '\''%{name}_%{version}-%{release}.%{arch}\n'\'''

alias rpm='rpm --qf '\''%{name}-%{version}-%{release}.%{arch}\n'\'''

echo '%_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}' >> /
etc/rpm/macro


Works for all shells ;-)

I've got an a %_query_all_fmt that also identifies srpm's and pubkeys
with suffixes
that I use when I'm bored.

73 de Jeff

[Jos Vos]

Post by Olaf Zaplinski
# rpm -q audit-libs
audit-libs_1.3.1-1.el5.x86_64
audit-libs_1.3.1-1.el5.i386
# rpm -e audit-libs_1.3.1-1.el5.i386
error: package audit-libs_1.3.1-1.el5.i386 is not installed

No, because the first _ (underscore) has to be a - (dash)!!!

I'm pretty sure "rpm -q audit-libs" does not give the output you say...

[Olaf Zaplinski]

Post by Jos Vos
No, because the first _ (underscore) has to be a - (dash)!!!

Yes, that was the problem. Thanks, Jos! I do not remember where I found
that rpm alias workaround, but it is obviously wrong.

Olaf

[Paul Johnson]

Post by Olaf Zaplinski
Hi,
which package manager would you recommend for a RHEL5 system? rpm alone
# rpm -q audit-libs
audit-libs_1.3.1-1.el5.x86_64
audit-libs_1.3.1-1.el5.i386
# rpm -e audit-libs_1.3.1-1.el5.i386
error: package audit-libs_1.3.1-1.el5.i386 is not installed

You dont need version info in rpm -e.

This comes up now and then with rpm new users. The argument following
the -e should be the PACKAGE NAME. On an i386 system I have

$ rpm -qa | grep audit
audit-libs-python-1.5.6-2.fc7
audit-libs-1.5.6-2.fc7

and to remove audit-libs (the package name), type

$ rpm -e audit-libs

Now, on the X86_64 system, one will usually find both the i386 and
x86_64 libs installed. This is not a flaw or mistake, it is a multilib
feature developed. This way, programs that have 64 bit
implementations can be used, but 32 bit programs that need the
audit-libs functionality can find it. The dynamic linker for
libraries looks in /usr/lib64 first, then /usr/lib.
Generally, this does not cause trouble on our 64 bit systems.

To remove audit-libs,

$ rpm -e audit-libs --all-matches

Post by Olaf Zaplinski
Olaf
_______________________________________________
Rpm-list mailing list
https://www.redhat.com/mailman/listinfo/rpm-list

[Wichmann, Mats D]

Post by Paul Johnson
Now, on the X86_64 system, one will usually find both the i386 and
x86_64 libs installed. This is not a flaw or mistake, it is a multilib
feature developed. This way, programs that have 64 bit
implementations can be used, but 32 bit programs that need the
audit-libs functionality can find it. The dynamic linker for
libraries looks in /usr/lib64 first, then /usr/lib.

yes, but the way this appears in rpm in Red Hat's implementation
is horribly nonintuitive. You have to go grokking for special
arguments to give rpm to figure out which package is which,
should you have a reason to operate on only one of them.
Most other distros have chosen to tag the package names in a
way that they can be identified visually; this is not "better"
in a technical sense but sure is easier to use.

[seth vidal]

Post by Wichmann, Mats D

Post by Paul Johnson
Now, on the X86_64 system, one will usually find both the i386 and
x86_64 libs installed. This is not a flaw or mistake, it is a multilib
feature developed. This way, programs that have 64 bit
implementations can be used, but 32 bit programs that need the
audit-libs functionality can find it. The dynamic linker for
libraries looks in /usr/lib64 first, then /usr/lib.

yes, but the way this appears in rpm in Red Hat's implementation
is horribly nonintuitive. You have to go grokking for special
arguments to give rpm to figure out which package is which,
should you have a reason to operate on only one of them.
Most other distros have chosen to tag the package names in a
way that they can be identified visually; this is not "better"
in a technical sense but sure is easier to use.

Which is a good reason to list your installed pkgs using any of the
package managers that operate above rpm.

yum list installed
will output like this, for example:
yum.noarch 3.2.7-1 installed
yum-metadata-parser.i386 1.1.2-1.fc8 installed

So there's no doubt about which arch you have installed.

-sv

[Jeff Johnson]

Post by seth vidal

Post by Wichmann, Mats D

Post by Paul Johnson
Now, on the X86_64 system, one will usually find both the i386 and
x86_64 libs installed. This is not a flaw or mistake, it is a multilib
feature developed. This way, programs that have 64 bit
implementations can be used, but 32 bit programs that need the
audit-libs functionality can find it. The dynamic linker for
libraries looks in /usr/lib64 first, then /usr/lib.

yes, but the way this appears in rpm in Red Hat's implementation
is horribly nonintuitive. You have to go grokking for special
arguments to give rpm to figure out which package is which,
should you have a reason to operate on only one of them.
Most other distros have chosen to tag the package names in a
way that they can be identified visually; this is not "better"
in a technical sense but sure is easier to use.

Which is a good reason to list your installed pkgs using any of the
package managers that operate above rpm.
yum list installed
yum.noarch 3.2.7-1 installed
yum-metadata-parser.i386 1.1.2-1.fc8 installed
So there's no doubt about which arch you have installed.

cat << GO_SYSIN_DD >> /etc/rpm/macros
%_query_all_fmt %%{name}.%%{arch} %%{version}-%%{release}
installed
GO_SYSIN_DD

$ rpm -q yum
yum.noarch 3.2.7-1.fc8 installed


Then there's no confusion about what "yum list installed" is actually
doing, or why yum chose to install multilib packages in the first place.

73 de Jeff

[Wichmann, Mats D]

Post by seth vidal
Which is a good reason to list your installed pkgs using any of the
package managers that operate above rpm.
yum list installed
yum.noarch 3.2.7-1 installed
yum-metadata-parser.i386 1.1.2-1.fc8 installed
So there's no doubt about which arch you have installed

yes, certainly agree with that message

(just like debian people have long known dpkg isn't
where they want to be fiddling)

[Jeff Johnson]

Post by Wichmann, Mats D
yes, certainly agree with that message
(just like debian people have long known dpkg isn't
where they want to be fiddling)

So apt is necessary to configure dpkg? I dinna know that ...

73 de Jeff

[Bob Proulx]

Post by Jeff Johnson

Post by Wichmann, Mats D
yes, certainly agree with that message
(just like debian people have long known dpkg isn't
where they want to be fiddling)

So apt is necessary to configure dpkg? I dinna know that ...

[Of course Jeff is having fun with us...]

'apt' is as necessary for 'dpkg' as 'yum'/'urpmi'/etc. is for 'rpm'.
Which is to say that it is not. But it is still very useful and
arguably a good way to use the tools.

Bob

[Jeff Johnson]

Post by Bob Proulx
'apt' is as necessary for 'dpkg' as 'yum'/'urpmi'/etc. is for 'rpm'.
Which is to say that it is not. But it is still very useful and
arguably a good way to use the tools.

You miss the point.

Sure apt and yum are useful and needed.

Displaying the arch of a package using apt/yum is
hardly useful or needed when it can be trivially
done by configuring rpm.

Which is (or was) the context of this thread.

73 de Jeff