Zypper and "automatic" package tracking - Suse

This is a discussion on Zypper and "automatic" package tracking - Suse ; Can zypper keep track of "automatically" versus explicitly-installed packages, in the same way that the apt package manager does? E.g., suppose I were to install the package for mc, which has libslang2 as a dependency. Later, I remove the mc ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 27

Thread: Zypper and "automatic" package tracking

  1. Zypper and "automatic" package tracking

    Can zypper keep track of "automatically" versus explicitly-installed
    packages, in the same way that the apt package manager does?

    E.g., suppose I were to install the package for mc, which has libslang2
    as a dependency. Later, I remove the mc package. Would zypper now know
    that it is safe to remove libslang2 from my system, as it is unused by
    any explicitly installed software?

    Thanks,
    Mark

    --
    Mark Shroyer, http://markshroyer.com/contact/

  2. Re: Zypper and "automatic" package tracking

    Mark Shroyer wrote:
    > Can zypper keep track of "automatically" versus explicitly-installed
    > packages, in the same way that the apt package manager does?


    I have no idea what apt does, so no idea. Apt is so long out of support
    it isn't even funny anymore. It has beeen replaced by smart.

    > E.g., suppose I were to install the package for mc, which has libslang2
    > as a dependency. Later, I remove the mc package. Would zypper now know
    > that it is safe to remove libslang2 from my system, as it is unused by
    > any explicitly installed software?


    Are you saying if you can later remove libslang2 or if it will remove
    libslang2 when you remove mc?

    Do it and give us feedback on what happens on your machine.

    houghi
    --
    You are about to enter another dimension, a dimension not only of
    sight and sound but of mind. A journey into a wondrous land of
    imagination. Next stop, Usenet!

  3. Re: Zypper and "automatic" package tracking

    On Tuesday, October 14th, 2008 at 23:07:55h -0400, Mark Shroyer wrote:
    > Can zypper keep track of "automatically" versus explicitly-installed
    > packages, in the same way that the apt package manager does?


    It is irrelevant whether a package is installed automatically, explicity,
    manually or whatever.

    What is important is that the package manager knows that package A
    depends on package B, which may or may not depend on package C.

    Therefore if you want to remove package C, it will complain.

    If you decide to remove package A, then if nothing else depends on
    it, it will let you remove package A.

    If you recall, on apt systems, in order to detect whether or not
    package C or even B is no longer needed, you either have to try
    to remove them and see if it complains, or you run another utility
    eg deb-orphan and or deb-foster.

    It would be nice if the openSUSE package management system displayed
    redundant packages in a similar manner.

    > Would zypper now know that it is safe to remove libslang2 from my
    > system, as it is unused by any explicitly installed software?


    Why do you not try it and find out yourself?

    And then reinstall it.

    And then you could reinstall mc and learn if zypper was clever enough
    to know that libslang2 was already installed and not need to reinstall
    it.

  4. Re: Zypper and "automatic" package tracking

    J G Miller wrote:
    > If you recall, on apt systems, in order to detect whether or not
    > package C or even B is no longer needed, you either have to try
    > to remove them and see if it complains, or you run another utility
    > eg deb-orphan and or deb-foster.
    >
    > It would be nice if the openSUSE package management system displayed
    > redundant packages in a similar manner.


    At the last FOSDEM they talked about this, but from the people in the
    audience this was more a nice to have then a must have. The reason is
    that many people have pretty recent systems. This means more then enough
    HD space.

    So if I install A and B is autonagically installed as well and I then
    remove A and B stays behind, all that it does is take up space.

    Priorities went to making zypper faster. Much faster. The amount of work
    they would have to put into it is pretty high and they would need to
    take those people away from other projects.

    For a simple program, this can easily be done, but pretty fast it
    becomes very complex. Just try it for uourself and remove random
    programs. Many will complain, but many will not and I am pretty sure you
    will end up with a system that at best give some errors from time to
    time.

    houghi
    --
    You are about to enter another dimension, a dimension not only of
    sight and sound but of mind. A journey into a wondrous land of
    imagination. Next stop, Usenet!

  5. Re: Zypper and "automatic" package tracking

    On Wed, 15 Oct 2008 15:23:40 +0200, houghi wrote:
    > So if I install A and B is autonagically installed as well and I then
    > remove A and B stays behind, all that it does is take up space.


    Which means it takes longer for the system to find things that it
    does want to use, because it has to skip over all the unecessary detritus.

    The time may well be practically negligible, but your statement that all
    it does is take up space overlooks this fact.

  6. Re: Zypper and "automatic" package tracking

    J G Miller wrote:
    > On Wed, 15 Oct 2008 15:23:40 +0200, houghi wrote:
    >> So if I install A and B is autonagically installed as well and I then
    >> remove A and B stays behind, all that it does is take up space.

    >
    > Which means it takes longer for the system to find things that it
    > does want to use, because it has to skip over all the unecessary detritus.


    When would it do this? The only moment I can come up with is that an
    `updatedb` and `makewhatis` are slower (and probably beagle as well). I
    do not see where a file that is not linked to anything would slow
    something else down.

    Please elaborate.

    houghi
    --
    You are about to enter another dimension, a dimension not only of
    sight and sound but of mind. A journey into a wondrous land of
    imagination. Next stop, Usenet!

  7. Re: Zypper and "automatic" package tracking

    On Wed, 15 Oct 2008 17:01:14 +0200, houghi wrote:
    > I do not see where a file that is not linked to anything would slow
    > something else down.

    Well when you fire up an application A, it often needs to access
    an associated dynamic link library L in /usr/lib and often needs to
    access some data files S in /usr/share.

    Now in order to find the necessary library L and data files S,
    is not some searching through all the inodes in the respective
    directories necessary until the appropriately named file is found?

    With increasing numbers of files/directories in each /usr/lib and
    /usr/share, is it not going to take just that tiny fractionally longer?

  8. Re: Zypper and "automatic" package tracking

    J G Miller wrote:
    >
    >
    > On Wed, 15 Oct 2008 17:01:14 +0200, houghi wrote:
    > > I do not see where a file that is not linked to anything would slow
    > > something else down.

    > Well when you fire up an application A, it often needs to access
    > an associated dynamic link library L in /usr/lib and often needs to
    > access some data files S in /usr/share.


    Ok, let's asume it looks for /usr/lib/sample. Then it will look for
    /usr/lib/sample

    > Now in order to find the necessary library L and data files S,
    > is not some searching through all the inodes in the respective
    > directories necessary until the appropriately named file is found?


    I doubt that very much.

    > With increasing numbers of files/directories in each /usr/lib and
    > /usr/share, is it not going to take just that tiny fractionally longer?


    I doubt that very much. Perhaps in a very theoretical way and if you
    have several hundred thousand files in a directory. Under standard
    situations I would call it a non-event.

    houghi
    --
    You are about to enter another dimension, a dimension not only of
    sight and sound but of mind. A journey into a wondrous land of
    imagination. Next stop, Usenet!

  9. Re: Zypper and "automatic" package tracking

    On Wed, 15 Oct 2008 19:47:52 +0200, houghi wrote:

    >> Now in order to find the necessary library L and data files S,
    >> is not some searching through all the inodes in the respective
    >> directories necessary until the appropriately named file is found?


    > I doubt that very much.


    So, instead of expressing your doubt, please explain how the file is
    found.

    > I doubt that very much. Perhaps in a very theoretical way


    Ignoring theory, explain the method in practice then, please.

    > I would call it a non-event.


    I did say a very fractional amount of time, did I not?

    All of these non-events add up eventually.

  10. Re: Zypper and "automatic" package tracking

    J G Miller wrote:
    > > I doubt that very much. Perhaps in a very theoretical way

    >
    > Ignoring theory, explain the method in practice then, please.


    Please provide tests you have done and tell us how much time it is.

    > > I would call it a non-event.

    >
    > I did say a very fractional amount of time, did I not?
    >
    > All of these non-events add up eventually.


    Not in real life situations. Please provide proof if you have noticed
    that it does. I don't care enough to do tests.

    houghi
    --
    You are about to enter another dimension, a dimension not only of
    sight and sound but of mind. A journey into a wondrous land of
    imagination. Next stop, Usenet!

  11. Re: Zypper and "automatic" package tracking

    On Wed, 15 Oct 2008 20:51:01 +0200, houghi wrote:
    > Not in real life situations. Please provide proof if you have noticed
    > that it does. I don't care enough to do tests.

    The burden of proof does not lie with me, since it
    was you who provided the initial statement without
    any supporting evidence.

    Oh, and to clarify, when I stated searching through
    the inodes, I should have made it clearer that I
    was referring to the directory inodes.

  12. Re: Zypper and "automatic" package tracking

    On Tue, 14 Oct 2008 23:07:55 -0400, Mark Shroyer typed this message:

    > Can zypper keep track of "automatically" versus explicitly-installed
    > packages, in the same way that the apt package manager does?
    >
    > E.g., suppose I were to install the package for mc, which has libslang2
    > as a dependency. Later, I remove the mc package. Would zypper now know
    > that it is safe to remove libslang2 from my system, as it is unused by
    > any explicitly installed software?
    >
    > Thanks,
    > Mark


    Yes, usually. Suggest you use zypper --dry-run to check the dependencies
    before removing packages you're unsure about. I've accidently removed a
    single package that removed a ton of other packages I didn't want to
    delete.

  13. Re: Zypper and "automatic" package tracking

    J G Miller wrote:
    > > that it does. I don't care enough to do tests.

    > The burden of proof does not lie with me, since it
    > was you who provided the initial statement without
    > any supporting evidence.


    OK, I am sorry. I looked back and the first statement about speed was
    the following:


    Which means it takes longer for the system to find things that it
    does want to use, because it has to skip over all the unecessary
    detritus.


    I did not realize that was me who wrote that. My bad.

    houghi
    --
    > Beware of he who would deny you access to information, <
    > for in his heart he dreams himself your master. <
    > Commissioner Pravin Lal: "U.N. Declaration of Rights" <


  14. Re: Zypper and "automatic" package tracking

    On Wed, 15 Oct 2008, in the Usenet newsgroup alt.os.linux.suse, in article
    <1224078085_165@vo.lu>, J G Miller wrote:

    >houghi wrote:


    >> So if I install A and B is autonagically installed as well and I
    >> then remove A and B stays behind, all that it does is take up space.


    >Which means it takes longer for the system to find things that it
    >does want to use, because it has to skip over all the unecessary
    >detritus.


    Ah, but how do you define 'detritus'? Are you depending on some
    database that B was installed because of A - or the fact that you
    can 'stat' each file in package B, and find that none have been
    accessed since $DATE? But how is a relevant date determined? Since
    package A was removed? Or that the only time files in package B
    were accessed was when some file in package A was used?

    >The time may well be practically negligible, but your statement that
    >all it does is take up space overlooks this fact.


    When this (hypothetical) distribution got installed, it installed
    this useless editor $FOO, and I never use it because everyone knows
    you should only use $BAR, the true editor for the masses. So I'm
    stuck with $FOO-1.43.15.i686.rpm - and can't remove it because the
    freakin' security nanny program keeps reading the configuration files
    nightly to see that I've not set it to some mode that the nanny thinks
    is insecure, and that sets the ATIME so the package manager won't
    automatically throw this piece of dog poop out the window...

    There really is no simple answer.

    Old guy

  15. Re: Zypper and "automatic" package tracking

    On Wed, 15 Oct 2008 15:06:38 -0500, Moe Trin wrote:
    > Ah, but how do you define 'detritus'?


    In the scenario being discussed, package D which was installed
    because package B was installed, but package B was later removed
    and no other package requires package D. If package D is some
    library, rather than an actual application which could be used
    on its own, then it will not be used and is therefore what I
    would label as detritus.

    > When this (hypothetical) distribution got installed, it installed
    > this useless editor $FOO, and I never use it because everyone knows
    > you should only use $BAR, the true editor for the masses.


    In my experience, the only time you cannot uninstall $FOO after installing
    $BAR, is because somebody has constructed a base package which considers
    that $FOO must be installed.

    To give an example of a better arrangement in the apt/deb packaging
    system, a package can be defined as providing a generic facility eg
    "editor", so if it is a requirement of the system that an
    "editor" (regardless of flavor) must be installed, then so long as you
    select an editor which has been packaged specifiying that it provides
    "editor", then you can install that.

    > There really is no simple answer.

    Well deb-orphan and deb-foster get the job done on apt/deb systems.

  16. Re: Zypper and "automatic" package tracking

    On Wed, 15 Oct 2008 22:05:20 +0200, houghi wrote:

    > J G Miller wrote:
    >> > that it does. I don't care enough to do tests.

    >> The burden of proof does not lie with me, since it was you who provided
    >> the initial statement without any supporting evidence.

    >
    > OK, I am sorry. I looked back and the first statement about speed was
    > the following:
    >
    >
    > Which means it takes longer for the system to find things that it does
    > want to use, because it has to skip over all the unecessary detritus.
    >

    >
    > I did not realize that was me who wrote that. My bad.
    >
    > houghi


    If you have a collection A consisting of ten files and a collection B
    consisting of thirty files, in which collection will it on average take
    longer to find the relevant file?

  17. Re: Zypper and "automatic" package tracking

    On Wed, 15 Oct 2008 15:06:38 -0500
    ibuprofin@painkiller.example.tld (Moe Trin) wrote:

    >When this (hypothetical) distribution got installed, it installed
    >this useless editor $FOO, and I never use it because everyone knows
    >you should only use $BAR, the true editor for the masses.


    Now *that* is just plain wrong *and* ridiculous! Anyone with more than
    two brain cells to rub together knows, absolutely, that $FOO is a far,
    far better editor than that skanky old $BAR.

    So there. ;-)


    --
    Kevin Nathan (Arizona, USA)
    Linux Potpourri and a.o.l.s. FAQ -- (temporarily offline)

    Open standards. Open source. Open minds.
    The command line is the front line.
    Linux 2.6.25.16-0.1-pae
    8:44pm up 25 days 1:45, 18 users, load average: 1.19, 1.35, 1.28


  18. Re: Zypper and "automatic" package tracking

    J G Miller wrote:
    > If you have a collection A consisting of ten files and a collection B
    > consisting of thirty files, in which collection will it on average take
    > longer to find the relevant file?


    I bet you are going to tell me with proof. Word of advice, use 10.000
    and 30.000 files. That makes the difference a lot easier to look at.

    I once did some tests on different file systems, and to make some
    serious difference, we used 100.000 files ad that was testing the file
    system itself. HUGE differences there.

    So please let everybody know how you did the test and what the results
    were . I am sure not only me is interested to read it but can't be
    botherd to actualy do it.

    houghi
    --
    > Beware of he who would deny you access to information, <
    > for in his heart he dreams himself your master. <
    > Commissioner Pravin Lal: "U.N. Declaration of Rights" <


  19. Re: Zypper and "automatic" package tracking

    Kevin Nathan wrote:
    > Now *that* is just plain wrong *and* ridiculous! Anyone with more than
    > two brain cells to rub together knows, absolutely, that $FOO is a far,
    > far better editor than that skanky old $BAR.


    $BAR needs you to _have_ more then two braincells to use it. So the fact
    that you use $FOO says more about you then about the editor.

    houghi
    --
    > Beware of he who would deny you access to information, <
    > for in his heart he dreams himself your master. <
    > Commissioner Pravin Lal: "U.N. Declaration of Rights" <


  20. Re: Zypper and "automatic" package tracking

    On Thu, 16 Oct 2008, in the Usenet newsgroup alt.os.linux.suse, in article
    <1224110075_1@vo.lu>, J G Miller wrote:

    >Moe Trin wrote:


    >> Ah, but how do you define 'detritus'?


    >In the scenario being discussed, package D which was installed
    >because package B was installed, but package B was later removed
    >and no other package requires package D. If package D is some
    >library, rather than an actual application which could be used
    >on its own, then it will not be used and is therefore what I
    >would label as detritus.


    Libraries, and other "non-user" type of packages, I can agree.

    >> When this (hypothetical) distribution got installed, it installed
    >> this useless editor $FOO, and I never use it because everyone knows
    >> you should only use $BAR, the true editor for the masses.


    >In my experience, the only time you cannot uninstall $FOO after
    >installing $BAR, is because somebody has constructed a base package
    >which considers that $FOO must be installed.


    I've seen that situation. And often it is an editor, though why a
    _specific_ one (other than 'sed') might be required is beyond me[1].
    But I have seen (generally non "main-stream") distributions require
    one, and the choice is sometimes quite bizarre (I recall one where
    /bin/vi, /bin/ed, and /bin/ex were all _links_ to pico or nano or
    similar.) Yes, you need an editor to tweak configuration files, but
    a lot of distributions have decided that they will provide a
    proprietary admin tool to do things like editing /etc/hosts or similar
    tasks. It really gets interesting when you are trying to support a
    number of distributions (each of which knows "the right way" of doing
    many rudimentary tasks).

    Interestingly, the Filesystem Hierarchy Standard requires 'sed' and
    has '/bin/ed' as the only (optionally) required editor. Yet I've
    almost never seen a *nix installation without something acting as
    /bin/vi. A quick scan of the Linux Standard Base also seems only to
    mention 'sed' and no other editor.

    >> There really is no simple answer.


    >Well deb-orphan and deb-foster get the job done on apt/deb systems.


    'deb-orphan' appears to be similar to a really dumb script we've been
    using in the configuration management section for about ten years. If
    you have the 'rpm(8) man page, look at the query options and
    specifically '--whatrequires '. I don't have access to the
    script here, but from memory, it's something like

    rpm -qa | while read PACKAGE
    do
    rpm -q --whatrequires $PACKAGE | grep -q 'no package requires'
    if [ $? -eq 0 ] ; then
    echo "Package $PACKAGE has no dependents"
    fi
    done

    though I'm sure there is more to the script than that.

    Old guy

+ Reply to Thread
Page 1 of 2 1 2 LastLast