On Tue, 2008-11-18 at 17:12 -0500, Seth Vidal wrote: > > On Tue, 18 Nov 2008, Jesse Keating wrote: > > > On Tue, 2008-11-18 at 17:04 -0500, Michael DeHaan wrote: > >>> Couldn't both the above be solved by 'subscribing' to those sets of > >>> packages via say PackageKit? That way when PackageKit goes to look for > >>> updates, it only asks for updates for those particular packages. When > >>> you update, if anything else is needed to satisfy newer builds of those > >>> packages they can be pulled in. > >>> > >>> Of course, what we'd likely see is a combo of "Give me all security > >>> updates" and also "Give me updates only for these sets of packages". > >>> The interesting question is how to design UI around the subscriptions. > >>> > >>> > >> > >> I think I like this. > >> > >> In the case of "I just want a newer OpenOffice" and don't touch > >> everything else, that's already covered by a yum install today -- but we > >> do need something for the update case(s). > > > > The upside here is that it's purely client side code. We don't have to > > change anything about how we prepare and publish updates. > or you want to list a set of apps you want newer versions of and as little > else as possible? > yum update really means yum update openoffice\* somestuff\* \ > my_favorite_pkg\* I feel, you just discovered what apt/apt-get calls "package pinning" Ralf -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
