[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: yum annoyances

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.


Matt Wilson
rPath, Inc.
msw rpath com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]