Posts: 19,982
Joined: May 2009
Reputation:
452
nickr
Retired Team-Kodi Member
Posts: 19,982
No but it certainly stifles development.
Many addons start with people playing around and installing their "homemade" addon directly in their kodi install. They shouldn't have to put their addon in the repo or compile kodi themselves to be able to install from a zip file or their own repo.
If I have helped you or increased your knowledge, click the 'thumbs up' button to give thanks :) (People with less than 20 posts won't see the "thumbs up" button.)
Posts: 103
Joined: Feb 2015
Reputation:
5
V8MEM
Senior Member
Posts: 103
instead of this minor stop-gap, why not put the tivoization of kodi into full gear and only allow signed addons by selected elite coders.
Posts: 5,952
Joined: Sep 2008
Reputation:
201
Koying
Retired Team-Kodi Member
Posts: 5,952
What Martijn says.
You *don't* need a repo for addon development.
Even if the addon has dependecies, you *still* can install the dependency manually, assuming the dependency is meant to be added to the official repo,
I suspect 99.99% of the addon developers use a desktop OS, anyway, so they even can develop in-place, without "installing" anything...
Posts: 6,255
Joined: Jun 2009
Reputation:
115
da-anda
Team-Kodi Member
Posts: 6,255
2017-08-30, 13:04
(This post was last modified: 2017-08-30, 13:05 by da-anda.)
from what I gathered, the PR does nothing else than to ensure that add-ons with the same ID that exist on multiple repositories AND the Kodi repository will only be available from the Kodi repository. If people would like to fork/modify one of these add-ons and put it in their repository, all they have to do is to use a different add-on ID (which they should do anyways). This change basically only forces third party repositories to use different add-on IDs for add-ons that are copies/modifications of add-ons from the official repository. This simply ensures that users will get what they intended to install
Posts: 783
Joined: May 2016
Reputation:
280
2017-08-30, 15:50
(This post was last modified: 2017-08-30, 16:08 by anxdpanic.)
This seems like it would make testing repos obselete and install from zip would end up being goto for user testing.
'.dev' as test releases doesn't really seem feasible to me. External apps, other add-ons depending on addon.in.dev, or add-ons relying on dependency.in.dev would require all hardcoded add-ons id's changed for users to properly test. (No thank you)
Don't see it fostering debranding or forking either really, as it'd be much easier to long term maintain a service.unknown_source.updater
An alternate option might be to use official as the default override and always the override if official addon version > than x.repo addon version. Then if a user does a manual update and chooses an add-on from a repo that is not the current override*, prompt and allow the user to set that repo as the default override for that add-on(except for official addon version > than x.repo addon version). This should allow for test repositories and normal flow while providing control of unexpected/unintended add-on updates.
* edit: unknown source repo -> repo that is not the current override