>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.
You haven't justified need. They are either installed, or not, and existence of files and directories already indicates the patchlevel.
