On 2017-05-15 Mon 01:31, Theo de Raadt wrote: > >2) Notion of transactions > > > >Often, more patches are installed at once, with the single `syspatch` > >command. One might want to be able to revert all those patches at once > >as well. A notion of transactions could be made by adding a notion > >of transactions, but that would add more unnecessary complexity. > > > >It can be solved simpler way, by adding the line with the list of > >patches applied, e.g. > > > > # syspatch > > Installing patch 005_pf_src_tracking > > Get/Verify syspatch61-006_libssl.tgz 100% |*************| 2276 KB 00:04 > > Installing patch 006_libssl > > Get/Verify syspatch61-007_freetyp... 100% |*************| 732 KB 00:01 > > Installing patch 007_freetype > > Missing set, skipping patch 007_freetype > > Patches applied: 5,6 > > > >and by adding support for -r optional argument, which could be comma > >separated > >patch number list. > > That is incorrect. > > The usage situations are no patches, or all of the patches, or a > subset and you are about to install to get more /all of them. You > don't get to choose which you want, unless all newer ones are ripped out also. > > We don't manage dependencies. > > This tooling is designed to make errata handling EASY FOR US. Otherwise, > we would not bother building this service. >
Here i agree. If not providing easy ability to revert arbitrary list of patches, what about handle "transactions" or "syspatch sessions" or "patchsets" internally: After successful application of patch(es), create /var/syspatch/patchset.$TIMESTAMP with list of applied patches (line by line). Reverting the last patchset would be reverting the patches from the last patchset file, and removing that file.
