hidden rpm ownership of links
David Mathog
lists with that on the previous system. I've just discovered that links
created by RPMs are (at least in some cases) not recorded in the rpm
"provided" information. For instance, on the previous system there
was a cdrecord rpm, but not on this one. Yet there is a cdrecord
program. So where did it come from? Observe:
# which cdrecord
/usr/bin/cdrecord
# rpm -q --whatprovides /usr/bin/cdrecord
file /usr/bin/cdrecord is not owned by any package
# ls -al /usr/bin/cdrecord
lrwxrwxrwx 1 root root 26 Jun 27 09:35 /usr/bin/cdrecord ->
/etc/alternatives/cdrecord*
# rpm -q --whatprovides /etc/alternatives/cdrecord
file /etc/alternatives/cdrecord is not owned by any package
# ls -al /etc/alternatives/cdrecord
lrwxrwxrwx 1 root root 14 Jun 27 09:35 /etc/alternatives/cdrecord ->
/usr/bin/wodim*
# rpm -q --whatprovides /usr/bin/wodim
cdrkit-1.1.2-4mdv2007.1
Is cdrkit enough to cause /usr/bin/cdrecord to be created?
# rpm -e cdrkit xcdroast #had a dependency on cdrecord
# ls -al /usr/bin/cdrecord
ls /usr/bin/cdrecord: No such file or directory
# urpmi cdrkit
# ls -al /usr/bin/cdrecord
lrwxrwxrwx 1 root root 26 Jul 5 10:12 /usr/bin/cdrecord ->
/etc/alternatives/cdrecord*
# rpm -q --whatprovides /usr/bin/cdrecord
file /usr/bin/cdrecord is not owned by any package
So yes, cdrkit is solely responsible for the creation of
/usr/bin/cdrecord. rpm retains no record of this that it will
disclose with "--whatprovides", yet it does remember, as uninstalling
the rpm also removes the link.
Why aren't links created by rpm's counted under "--whatprovides"?
Regards,
David Mathog
Unruh
Because they are not files listed in the file list of the package. They
come about because the post install script in the rpm makes those links.
David Mathog
> David Mathog <mat...@caltech.edu> writes:
>
>> Why aren't links created by rpm's counted under "--whatprovides"?
>
>
> Because they are not files listed in the file list of the package. They
> come about because the post install script in the rpm makes those links.
So? It's a change made by the rpm to the system. It is for all intents
and purposes a file. More importantly, there is the possibility of a
collision between packages, where one package installs a link and then
another installs an actual file. (Or maybe not, if the installation
fails when it sees that the link exists, but in any case, there won't be
nice collision warning and no attempted install at all.)
Anyway, it seems kind of incomplete to me for RPM not to keep track of
everything it does to the file system.
Regards,
David Mathog
Dan Espen
I think I agree.
The solution is as you describe, before looking up a file
with RPM, find out if it's a soft link and what the real file
is.
As long as the soft link is provided by a script,
I don't know if the situation will improve. Scripts
are by definition pretty hard to parse.
If you contact the RPM developers they may be willing to
at least document the problem in the man page.
Robert M. Riches Jr.
I'm pretty sure I have seen actual real files that were
created by the post-install scripts that were not
acknowledged by "rpm -qf $file" as being owned by any
package.
--
Robert Riches
spamt...@verizon.net
(Yes, that is one of my email addresses.)
Dan Espen
Well, a script can create a link or a file.
At the very least the rpm man page could list the
limitations of the --what-provides argument.
David Mathog
> If you contact the RPM developers they may be willing to
> at least document the problem in the man page.
Good point, I just sent something to their mailing list and I'll report
back with whatever they come up with.
Thanks,
David Mathog
Unruh
>Unruh wrote:
>> David Mathog <mat...@caltech.edu> writes:
>>
>>> Why aren't links created by rpm's counted under "--whatprovides"?
>>
>>
>> Because they are not files listed in the file list of the package. They
>> come about because the post install script in the rpm makes those links.
>So? It's a change made by the rpm to the system. It is for all intents
>and purposes a file. More importantly, there is the possibility of a
You may think so. The packagers do not. Sorry. YOu can shout and scream and
stamp your feet all you want.
>collision between packages, where one package installs a link and then
>another installs an actual file. (Or maybe not, if the installation
>fails when it sees that the link exists, but in any case, there won't be
> nice collision warning and no attempted install at all.)
Sure.
>Anyway, it seems kind of incomplete to me for RPM not to keep track of
>everything it does to the file system.
Fine.
Now you have that off your chest.
Unruh
>David Mathog <mat...@caltech.edu> writes:
It is NOT the rpm problem. It is the problem of the packager.
There is no way rpm can know about changes you made to the system in the
post install script. It cannot parse the script and figure out what youwere
doing.
Dan Espen
I can't figure out what you are ranting about.
All I suggested is that the rpm man page be updated.
I know parsing scripts can be difficult.
That's not to say that the RPM format itself can't be updated to include
a list of things that may be created by the script.
But I didn't suggest that. That's something
the developers may come up with.
Joerg Schilling
David Mathog <mat...@caltech.edu> wrote:
>I'm slowly going through the new 2007.1 server and comparing the rpm
>lists with that on the previous system. I've just discovered that links
>created by RPMs are (at least in some cases) not recorded in the rpm
>"provided" information. For instance, on the previous system there
>was a cdrecord rpm, but not on this one. Yet there is a cdrecord
>program. So where did it come from? Observe:
>
># which cdrecord
>/usr/bin/cdrecord
># rpm -q --whatprovides /usr/bin/cdrecord
>file /usr/bin/cdrecord is not owned by any package
># ls -al /usr/bin/cdrecord
>lrwxrwxrwx 1 root root 26 Jun 27 09:35 /usr/bin/cdrecord ->
>/etc/alternatives/cdrecord*
># rpm -q --whatprovides /etc/alternatives/cdrecord
>file /etc/alternatives/cdrecord is not owned by any package
># ls -al /etc/alternatives/cdrecord
>lrwxrwxrwx 1 root root 14 Jun 27 09:35 /etc/alternatives/cdrecord ->
>/usr/bin/wodim*
># rpm -q --whatprovides /usr/bin/wodim
>cdrkit-1.1.2-4mdv2007.1
>
>Is cdrkit enough to cause /usr/bin/cdrecord to be created?
I fear this.....
If you cannot safely remove these links and replace them with
original software, you should definitely file a bug!
Check the original at http://cdrecord.berlios.de/new/private/cdrecord.html
which in contraty to the dead fork "cdrkit" is actively developed.
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily