hidden rpm ownership of links - Mandriva

This is a discussion on hidden rpm ownership of links - Mandriva ; 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. ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: hidden rpm ownership of links

  1. hidden rpm ownership of links

    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?

    # 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

  2. Re: hidden rpm ownership of links

    David Mathog writes:

    >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?


    ># 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"?



    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.




  3. Re: hidden rpm ownership of links

    Unruh wrote:
    > David Mathog 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




  4. Re: hidden rpm ownership of links

    David Mathog writes:

    > Unruh wrote:
    >> David Mathog 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.


    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.

  5. Re: hidden rpm ownership of links

    On 2007-07-05, Dan Espen wrote:
    > David Mathog writes:
    >
    >> Unruh wrote:
    >>> David Mathog 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.

    >
    > 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.


    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
    spamtrap42@verizon.net
    (Yes, that is one of my email addresses.)

  6. Re: hidden rpm ownership of links

    "Robert M. Riches Jr." writes:

    > On 2007-07-05, Dan Espen wrote:
    >> David Mathog writes:
    >>
    >>> Unruh wrote:
    >>>> David Mathog 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.

    >>
    >> 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.

    >
    > 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.


    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.

  7. Re: hidden rpm ownership of links

    Dan Espen wrote:

    > 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


  8. Re: hidden rpm ownership of links

    David Mathog writes:

    >Unruh wrote:
    >> David Mathog 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.

  9. Re: hidden rpm ownership of links

    Dan Espen writes:

    >David Mathog writes:


    >> Unruh wrote:
    >>> David Mathog 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.


    >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.


    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.


  10. Re: hidden rpm ownership of links

    Unruh writes:

    > Dan Espen writes:
    >
    >>David Mathog writes:

    >
    >>> Unruh wrote:
    >>>> David Mathog 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.

    >
    >>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.

    >
    > 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.


    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.

  11. Re: hidden rpm ownership of links

    In article ,
    David Mathog 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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
    js@cs.tu-berlin.de (uni)
    schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
    URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

+ Reply to Thread