yum annoyances

[Matt Wilson]

On Tue, Dec 06, 2005 at 12:22:22PM -0500, Jeff Spaleta wrote:
> On 12/6/05, Matthew Miller <mattdm at mattdm.org> wrote:
> > This could be worked around with an "obsolete-packages" rpm in the
> > repository, which would mark as Obsolete all such known packages.
> 
> Is that really appropriate? To unleash a package in a repository that
> will remove functionality from a client system?  What happens to user
> who were relying on that functionality?

Let me outline how this works in a Conary world[1].  The distribution
is defined by a hierarchical set of groups.  When a package is
replaced by another package, we build a special "redirect" in the
repository that moves you from one package to the other.  The
classical example of this is a migration from kbd to consoletools to
kbd.  This is somewhat similar to Obsoletes.

When it comes time to put a package out to pasture (that is, remove it
from the distribution altogether, when there is nothing that assumes
the functionality of the package), we just remove it from the group.
When the user updates to the new version of the group, the removal of
the package from the group is applied to the system (that is, the
package is removed from the systeM).  If the user depends on the
package, they can "pin" it on the system and it won't be removed.

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.

You may be able to apply this methodology to yum.  What do you think?

[1] Yes, I know everyone was dying to know!

Cheers,

Matt
-- 
Matt Wilson
rPath, Inc.
msw at rpath.com