On Mon, May 15, 2017 at 08:36:21AM +0000, Michal Bozon wrote:
> On 2017-05-15 Mon 02:23, Theo de Raadt wrote:
> > >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.
> > 
> 
> I think the justification is:
> 
> Why do i even need to revert a patch? Only because something got broken
> by the last syspatch command, that may have applied multiple patches.
> I might not now which patch caused the problem.
> 
> If the problematic patch was not the last one from the set,
> reverting with -r does not help, because it reverts single last patch only.
> 
> Well, applying `syspatch -r` repeatedly is a sort of solution as well.
> 

That would probably be a better solution (repeatedly removing the latest
patch), since I assume a new patch may depend on an earlier patch
existing.

However, if a patch is broken, it should be reported and then fixed, and
then a new patch will be rolled (if deemed necessary).

Regards,
Kusalananda

Reply via email to