[PATCH] base-files: sysupgrade: store status of system-services

[Alberto Bursi]

On 10/01/21 08:26, Reiner Karlsberg wrote:
> Am 10.01.2021 um 03:32 schrieb Alberto Bursi:
>  >
>  >
>  > On 09/01/21 12:56, Reiner Karlsberg wrote:
>  >> Am 09.01.2021 um 13:28 schrieb Stijn Segers:
>  >>
>  >>  > Currently all services get enabled during image creation. This 
> can cause
>  >>  > issues after upgrade with services explicitly disabled by the user.
>  >>  > With this created list sourced by a simple uci-defaults script 
> the state
>  >>  > can be restored automatically.
>  >>
>  >> Pls, do _NOT_ make this default.
>  >> There might be other entities, besides me, who already have
>  >> implemented methods to work around unnecessary enabled services.
>  >> I.e. to disable service in uci-defaults, like I do.
>  >> Auto-restore service state will break existing code.
>  >>
>  >> In general, I do _NOT_ consider it a good idea, to more or less
>  >> silently modify existing functionality.
>  >> Which happems often enough in openwrt, unfortunately.
>  >>
>  >> Best would be, to make this new behaviour optional. Do another 
> change for LuCI, and then this is done.
>  >>
>  >> In worst case, pls provide an option for sysupgrade _NOT_
>  >> to keep service state.
>  >>
>  >> Cheers,
>  >>
>  >> Reiner
>  >>
>  >>
>  >
>  >
>  > When you or some other entity decided to keep your workaround 
> downstream instead of contributing it you accepted the
>  > risk of someone else eventually fixing it in a way you don't like, or 
> in a moment you don't like.
> You can fix a bug, to modify existing code really to fulfil assumed 
> functionality.
> But we are talking about implementation of new (or modified) 
> functionality here.

not saving state of services on sysupgrade is a bug, at least imho.

What is the rationale for not saving service status on sysupgrade, 
beyond "not break my current custom downstream stuff" though?

Do you have a usecase where you are doing significantly more complex 
things that cannot be just migrated to a new standard where service 
status is preserved with a normal sysupgrade?

> 
>  >
>  > I disagree with making this optional just to save you and whatever 
> others had their own local workaround some trouble,
>  > if you have a bunch of downstream patches it's on you to deal with 
> it, you can't complain to the main project and ask to
>  > stop development because it's increasing your workload.>
>  > I think what you think is "worst case", is the only acceptable thing, 
> making it active by default and adding a setting
>  > to disable this function. Although it's useful only for your specific 
> usecase (i.e. the ones that actually have their
>  > own workaround in place). If this works there is no need to disable 
> it and re-invent the wheel.
> In this particular case, there is already the "-n" option available for 
> sysupgrade. Not to keep the settings.
> The proposed functionality would affect this well-known (?) existing 
> function.

This makes me think you misread the proposed change.

At the moment it's adding this functionality under the "-k" option (the 
"save packages" function), everything else is unaffected.

Using "-n" always overrides all other backup options. It means sysupgade 
will not write the "backup config tar" file at all.
So it does not matter what additional things are backed up by default or 
what other options you add to sysupgrade call, if you use "-n" nothing 
gets backed up.
This does not change, and nobody wants or wanted to change the "-n" option.

There are just 2 people (me, Andrew Heider) that would like to see 
saving service status done by default when sysupgrading, and other 2 
people that would like it in its own setting option (Stjin Segers and 
Paul Spooren).


> 
> However, in general, already half a century ago I knew the concept of 
> "modularity" in software engineering.
> Which also means, to keep existing functionality in case of changes. You 
> can also call it "backward compatibility".

Yeah but if a default is changed, the only "backward compatibility" that 
can be done is adding an option to "run in legacy mode", which is what I 
said was acceptable imho, but strange.

Others asked to place this in its own option instead to add it to an 
existing option.

> 
> Cheers,
> 
> Reiner
>  >
>  > -Alberto
>  >
>  > _______________________________________________
>  > openwrt-devel mailing list
>  > openwrt-devel at lists.openwrt.org
>  > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel