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@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel