Hi David, that was a good sugestion, but won't the list get too long if packages were differentiated on that basis, is there no other way these packages could be handled ??? On 4/2/08, David Timms <dtimms@xxxxxxxxxxxx> wrote: > seth vidal wrote: > > On Wed, 2008-04-02 at 06:39 +1100, David Timms wrote: > >> yum install foo > >> [foo renamed /etc/foo.cfg to /etc/foo.cfg.rpmold: versioned at ...] > >> [foo created /etc/foo.cfg: versioned at /var/cache/rollback/...] > >> > >> I guess that is a bit simplified; it's not just config files that can > >> get modified in scriptlets. Perhaps you could version the /etc/ folder > >> and commit any change after each yum transaction ? > > > > it's not just /etc > > > > think about updates like: > > mysql4 -> mysql5 > > > > you have to roll back the db versions > > and NOT roll back the data. > Perhaps it would still be useful to have rollback functionality that > knows about packages that aren't nice to rollback - and excludes them. > If it was a yum plugin, perhaps a proposed update could warn you before > hand that you wouldn't be able to rollback package X before the upgrade. > > There is also no way to be sure that an older version is still available > in any of the yum repos that are defined. > > I know this flies in the face of Fedora bug resolve by upstream release > paradigm ;-) , but sometimes stuff just has to work - now. > > DaveT. > _______________________________________________ > Yum mailing list > Yum@xxxxxxxxxxxxxxxxxxxx > https://lists.dulug.duke.edu/mailman/listinfo/yum > _______________________________________________ Yum mailing list Yum@xxxxxxxxxxxxxxxxxxxx https://lists.dulug.duke.edu/mailman/listinfo/yum
