On Mon, Jun 25, 2007 at 08:09:44PM -0400, Jesse Keating wrote: > On Monday 25 June 2007 18:40:54 Axel Thimm wrote: > > The reason is that if you build a security update against F7 & > > updates-released in 12 months and this requires a library that has > > been updated since F7's release (but not due to security), you will > > end up with a broken security update on a system following only > > security updates. So you're left with the following options: > > > > o forget about a security updates only mechanism, whether this is a > > yum-plugin or a separate repo > > o Elevate all dependencies of a security update to become part of the > > virtual or real security-update repo > > o Build security updates only against F7 & security updates, not all > > the updates (and only elevate non-security updates to security > > status to fulfill otherwise missing dependencies. > > > > At first the yum-plugin sounds like the easy way out, but it will > > generate more issues than it will solve especially the more F7 will be > > aging. > > Or simply design the yum-plugin to consider security updates only for > upgrades, then depsolve from there. It would be akin to just running 'yum > update <list of packages>'. It wouldn't look at your entire package set for > potential updates, just what you give it, and what it needs to depsolve from > there. In fact, I think that's the way the current plugin works. If for example glibc has been updated yum update foo will not pull it in. Try it. -- Axel.Thimm at ATrpms.net
Attachment:
pgp77KPYpRuqr.pgp
Description: PGP signature
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
