On Tue, Dec 06, 2005 at 12:22:22PM -0500, Jeff Spaleta wrote: > On 12/6/05, Matthew Miller <mattdm@xxxxxxxxxx> 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@xxxxxxxxx -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
