On Thu, 2006-12-07 at 10:04 +0100, Gianluca Sforna wrote: > On 12/7/06, seth vidal <skvidal@xxxxxxxxxxxxxx> wrote: > > Keep in mind this means keeping yet another package database to track > > more state for things on or off the system and the intent of the user at > > the time they last changed state. > > > > It's possible but we'd need to make sure this is wired into how the > > installer works, too. And did I mention it is yet another package > > database? > > > > However, the scenario: > 1. let try the xxx package to see if it is useful > 2. yum install xxx > 3. yyy and zzz are installed as deps > 4. ok, xxx is not that useful after all > 5. yum remove xxx > 6. yyy and zzz are still there > > seems pretty familiar to me. I usually resort to /var/log/yum.log to > have the list of packages to uninstall... > > Now I have a naive question: does it need a yet another package > database to remove, together with xxx, each package on which xxx > depends, under the constrain that xxx has to be the ONLY package > requiring it? > This is a different case. It's not something that could be done automatically. It would need to have another package db to do some-what correctly. By that I mean that there will be times when xxx is the only package that depends on yyy. But the people using the machine may have unpackaged software (possibly compiled from source, possibly they're developing a new product.) that makes use yyy as well. Having another db, you can track whether yyy was installed explicitly or as a requirement of another package. Even this isn't 100% accurate as you might have installed it originally as a dependency but have started using it for unpackaged software. At least in that case you can reinstall that software and it won't be uninstalled again. (Still problematic, though. If you build some software, a few months later uninstall something it depends on, and a few months later discover the software no longer works you may have a lot of work to figure out why.) -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
