[OpenWrt-Devel] [PATCH][CC] Revert "ar71xx: change some TP-link modelnames (WR841, WA701, WA730)"

[Tim Niemeyer]

Hi

* Bastian Bittorf <bittorf at bluebottle.com> [25-04-16 08:54]:
> * John Crispin <john at phrozen.org> [25.04.2016 07:39]:
> > > The changed image name breaks compatibility for derived projects and
> > > that's something which should only happen if there is a really good
> > > reason (e.g. security fix).
> > 
> > how does it beak compatibility ?
> 
> I think they auto-download a preconfigured filename,
The users are responsible for the download. They can choose between an
semi automated script (coded image name, based on the board name), or a
download from our site, or they can build their own, or they can use
images build by derived projects.

> which will ofcource not succeed. We circumvented this in our
> network-autoupdater in a way, that we download e.g. "$MODELNAME.bin"
> where $MODELNAME is from '/tmp/sysinfo/model' e.g. 'TP-Link TL-WDR4900 v1'
> and on the downloadserver we can "adjust" the symlinks...
Yes, we could change this names using filesystem links. But there is
more work to do besides that e.g. documentation.

We also can just revert the changes locally. But i think there are even
more projects providing OpenWrt images or e.g. download links to images
and they will probably also face some unexpected(!) problems.

> I'am against reverting the commit. Lets keep it, because it makes sense.
It totally makes sense, but it's a new feature and therefore it should be
only applied to master/trunk and not to a stable branch.

We use the stable branch because we don't want uncontrolled and
incompatible changes! The commit which is to be reverted breaks the
compatibility and doesn't bring an bug fix or an really important feature.

I guess a lot of users would be even more confused by this patch, at
least because some models still have an n or nd and some not. So apart
from compatibility problems on the stable branch, in my opinion the
feature is incomplete. But this is off topic and should be discussed
separately.

> Maybe i can give a short talk at Battlemesh v9 about proper autoupdates,
> because we have ~10 years experience in this (including 500 dead devices
> 8-)))
Sorry about the dead devices. Thanks for the offer, but the automatic
update is off topic and I'm currently not interested in it.

Tim