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.
>
> 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.
A reasonable compromise would be, to extend the functionality of "-n": In case "-n" is used, this also means, _NOT_ to
save the service states.
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".
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
