On Tue, Dec 06, 2005 at 05:05:03PM -0500, seth vidal wrote: > > > The interactive frontend can help guide users though the changes that > > are going to be made by performing an update. At that point, a user > > could decide to pin the package instead of allowing it to be removed. > > and for a non-interactive run of conary? What happens on the automated > runs? By default, the package will be removed if it was removed from a group that you have installed and it wasn't added to any other group you have installed -- _unless_ it creates a dependency problem. So, we're not removing important deprecated shared libraries that are needed by other things on the system. Our philosophy for the automated case is to do the thing that most people want by default. In this case we believe that it's better to be closer to the next version of the OS than it is to leave old packages littered around forever. We give the user two ways to rely on deprecated packages (1. pin them and 2. rely on dependencies to keep the system in a working state, even if it requires an old package) and we have rollback functionality that can be used to go back to the older state. That makes cleaning up old packages seem pretty safe to me. If removing packages seems a little to drastic, you can set up the groups in Conary one more way. You can create group-dist-deprecated, and add all of the obsoleted packages to that group with the default flag set to False. Users that have an affinity to old software can install group-dist-deprecated. When you remove something from the distribution (which is group-dist in our case), you would add it to group-dist-deprecated. If the user had group-dist-deprecated installed, the package won't be removed from the system. Cheers, Matt -- Matt Wilson rPath, Inc. msw@xxxxxxxxx -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
