ddns-scripts is broken since last major update

[Ansuel Smith]

Il giorno sab 26 set 2020 alle ore 14:48 Andre Heider
<a.heider at gmail.com> ha scritto:
>
> On 26/09/2020 12:54, Florian Eckert wrote:
> > Hello Andre,
> >
> > thanks for your remarks, but I have to say this is a master branch and
> > this is *not* a stable branch!
> > The current implementation is not maintainable so I thought we have to
> > refactor this package.
> > If something is changed then something can also be broken.
> > This is not intended but can happen.
> >
> >> but the non existing backwards compatibility sucks though. This move
> >> breaks every installation relying on a provider which now moved to the
> >> new package.
> >
> > There will always be new packages and you have to adapt.
> > The other possibility was to leave the new files in the ddns-scripts package.
> > This would have increased the size of the package!
> > Then others would have been upset about the size of the package.
> > How to do it there is always someone who doesn't like it!
>
> How about a package for each provider? Then you don't need to whip up
> your own update script, which needs special handling everywhere else.
> Just use the opkg infrastructure like everything else.
>
> If you want to keep backward capability, you could then
> * move the main script to a "core" package
> * create an "all" package, which just depends on all providers
> * make the package of the old name depend on those two
>
> That way, the ddns setup doesn't break for updates.
>

This is what we will do (to quickly fix the problem the ddns-script will depend
on the "all" script package. This way we can keep the core and the service file
separate and save compatibility). Creating a package for each service
is massive.
It would mean 73+ new package that just contain a json file.

> >
> >> And the `ddns` command is basically just a stripped down opkg in sh.
> >
> > Not everyone needs all service providers.
> > Therefore the possibility to download the providers and not to install
> > the package.
> > It is also possible that the service urls change during the life cycle
> > of the software.
> > This can be updated by downloading the service files.
> >
> >> I think this needs to be more user friendly and less setup breaking.
> >
> > As I said, thanks for the feedback I and Ansual are working on it.
> >
> > Regards,
> >
> > Florian
> >
>