+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Kodi related discussions (https://forum.kodi.tv/forumdisplay.php?fid=6)
+--- Thread: [Q&A] treat repository.xbmc.org as override repository (/showthread.php?tid=320752)
RE: [Q&A] treat repository.xbmc.org as override repository - User 325245 - 2017-08-31
* Does this work only for addons in KODI repository or for ANY repository? i.e. if I install addon from my repo, will I be unable to update from OTHER repo?
* Does this work only for AUTO UPDATES or for MANUAL updates as well?
RE: [Q&A] treat repository.xbmc.org as override repository - Koying - 2017-08-31
(2017-08-31, 09:40)DaLanik Wrote: * Does this work only for addons in KODI repository or for ANY repository? i.e. if I install addon from my repo, will I be unable to update from OTHER repo?Only KODI repository. If an addon is *not* in the Kodi repository, then if it is in multiple repos, the current rule apply.
(2017-08-31, 09:40)DaLanik Wrote: * Doe this work only for AUTO UPDATES or for MANUAL updates as well?
Both.
RE: [Q&A] treat repository.xbmc.org as override repository - Gade - 2017-08-31
(2017-08-31, 08:14)Koying Wrote:(2017-08-31, 00:37)Gade Wrote: Adding .dev would make testing and development a lot harder as people will need to install two skins.
I don't think so.
If your users want to use the "beta" channel, they'd just install the dev version from your repo, and uninstall the stable one.
The main difference is that, nowadays, it's a hard to revert decision, as reverting to stable means uninstalling the beta and your repo, and reinstalling stable.
With a different ID, you let your users choose:
- they install beta, like it, keep it and uninstall stable (if they want, they don't have to)
- or they decide they prefer stable, and uninstall it (or not, keeping it to see how the beta evolves)
You might notice that more users are willing to test and report on your betas if they know they can switch back to stable easily if something fails.
It's the same situation as with android apk, really. I already suggested to have a different ID for nightlies/alpha/beta to allow users to test without risking to destroy their stable setup, mimicking what many software does nowadays with "channels". That's what I do for SPMC.
Thanks for explaining the details.
I can definately see benefits doing it both ways, although I absolutely prefer doing things the "old" way.
Do anyone have any thoughts on my suggestion:
A solution would be adding an optional line to addon.xml where developers can write their testing repo, if they use one.
Code:
<repository>repository.gade</repository>This way addon developers can choose either to ad ".dev" to their development version in their testing repo, or they can choose doing things the "old" way and adding the repository line in addon.xml
I really don't see any disadvantages in this approach.
RE: [Q&A] treat repository.xbmc.org as override repository - Martijn - 2017-08-31
By adding that line those "bad" repos could still override official repo and we have gained nothing.
RE: [Q&A] treat repository.xbmc.org as override repository - trogggy - 2017-08-31
(2017-08-31, 10:47)Martijn Wrote: By adding that line those "bad" repos could still override official repo and we have gained nothing.Unless I'm missing something there would be 2 ways that line could be added:
1. The author of the official addon adds it, so anyone who installs his repo gets it from there.
2. The user installs an addon with that line manually (or edits addon.xml directly), and also installs a repo with a different version.
So how does a 'bad repo' override anything?
RE: [Q&A] treat repository.xbmc.org as override repository - Koying - 2017-08-31
(2017-08-31, 10:13)Gade Wrote: A solution would be adding an optional line to addon.xml where developers can write their testing repo, if they use one.
That could work indeed, functionally.
That will require a good bunch of coding, though, and will render "source" filtering (ie at repo refresh time) impossible.
Not worth the hassle, imho.
RE: [Q&A] treat repository.xbmc.org as override repository - Gracus - 2017-08-31
(2017-08-30, 19:46)natethomas Wrote:(2017-08-30, 18:39)DaLanik Wrote: You are becoming new Apple with these restrictions
I believe the team is very open to real feedback on this. They're probably going to be less open to feedback that is either a joke comparing them to Apple or feedback that suggests the writer isn't really aware of what the code is doing.
Seeing where this thread goes, it seems to me that the decision has already been made so no feedback needed
Almost all answer from a kodi team member in this thread is more about "it will be done this way" than "we think of doing it this way but let's talk about it"
And if you want feedback from skinners and addon devs, then why this thread has been put in a part of the forum where they probably almost never come?
Put links to this thread in the skinning and in the addons sections to make them aware of this
RE: [Q&A] treat repository.xbmc.org as override repository - Gade - 2017-08-31
(2017-08-31, 10:47)Martijn Wrote: By adding that line those "bad" repos could still override official repo and we have gained nothing.
Not at all.
Only addons in the official repo should be checked for the repository line in addon.xml
And only maintainers of the official addons can add this line then. Pretty simple.
RE: [Q&A] treat repository.xbmc.org as override repository - Gade - 2017-08-31
(2017-08-31, 11:34)Gracus Wrote: Seeing where this thread goes, it seems to me that the decision has already been made so no feedback needed
Almost all answer from a kodi team member in this thread is more about "it will be done this way" than "we think of doing it this way but let's talk about it"
And if you want feedback from skinners and addon devs, then why this thread has been put in a part of the forum where they probably almost never come?
Put links to this thread in the skinning and in the addons sections to make them aware of this
I completely agree.
Seems to me the decision has been made and very little discussion is possible.
RE: [Q&A] treat repository.xbmc.org as override repository - User 325245 - 2017-08-31
(2017-08-31, 13:10)Gade Wrote: Seems to me the decision has been made and very little discussion is possible.
As always.
Anyway, why not let the user MANUALY override this? Yes, the idea that there should be some protection makes sense, but only if you're on auto updates. If you're updating manualy - you will get the repo choose dialog any you know what you are doing, right
RE: [Q&A] treat repository.xbmc.org as override repository - da-anda - 2017-08-31
@Gade - what about dependencies of dev add-ons? Like, what if you work on a all new Rapier version that requires changes to some other script/library (skin helpers, ...) that are not in repo yet, and these changes might not be backwards compatible? So even if your skin could be overridden the way you suggested, what about the dependencies? At least to me it would make most sense to have a .dev version for all of these testing related add-ons/modules so that they can be tested without the risk to break other add-ons etc and with an easy way to revert to a stable version (like koying suggested). I don't see a real advantage of your suggestion (besides of keeping add-on settings, but Kodi could probably copy the settings from "non .dev" to ".dev" when such a version is installed).
RE: [Q&A] treat repository.xbmc.org as override repository - da-anda - 2017-08-31
(2017-08-30, 13:12)trogggy Wrote: A question - probably to the wrong audience, but you're the ones making it happen so presumably you know...It depends on the wizard. Many simply delete the entire "userdata" folder and replace it with preconfigured stuff and force a Kodi restart after that. So yes, as python is not sandboxed, malicious add-ons can do really bad things to your Kodi installation and entire computer/network.
Can wizards / builds override settings without a user input? As I understand it the third-party repo switch was introduced with exactly that in mind - users now have to make a decision. Doesn't it work? Or is it that users are making the wrong decisions?
RE: [Q&A] treat repository.xbmc.org as override repository - trogggy - 2017-08-31
(2017-08-31, 15:50)da-anda Wrote:Fair enough. Although probably not on mine with my boring repos.(2017-08-30, 13:12)trogggy Wrote: A question - probably to the wrong audience, but you're the ones making it happen so presumably you know...It depends on the wizard. Many simply delete the entire "userdata" folder and replace it with preconfigured stuff and force a Kodi restart after that. So yes, as python is not sandboxed, malicious add-ons can do really bad things to your Kodi installation and entire computer/network.
Can wizards / builds override settings without a user input? As I understand it the third-party repo switch was introduced with exactly that in mind - users now have to make a decision. Doesn't it work? Or is it that users are making the wrong decisions?
If someone's installing a build that overrides everything though, I can't see how this pr would make things any more secure. Other than a total block on 3rd party repo's nothing's going to stop that, is it? That (a total block) would be the pile of poop at the bottom of the slippery slope.
RE: [Q&A] treat repository.xbmc.org as override repository - anxdpanic - 2017-08-31
How will users be able to test external apps/other addons against .dev versions if the hardcorded id's don't match? Any hasAddons etc, are going to match and use stable and .dev remains untested in those scenarios.
For dependecies in .dev(especially in skins) or add-ons relying on plugin url's of other add-ons, we would need to update and track all hardcorded id's between versions. Skins would have this worse, especially if multiple .dev depends.
If this happens in the current state, having a user install from zip for ~alpha/beta/.xx versions seems like more scenarios can be tested and would be less burden to users and devs than using .dev. Generate the repository as usual and use the repository zip path as a release index/file system source... or deal with the extras that come with .dev.
RE: [Q&A] treat repository.xbmc.org as override repository - Koying - 2017-08-31
(2017-08-31, 17:22)anxdpanic Wrote: How will users be able to test external apps/other addons against .dev versions if the hardcorded id's don't match? Any hasAddons etc, are going to match and use stable and .dev remains untested in those scenarios.
You're losing me
Is it about a beta skin depending on a beta addon?
Then the beta skin should hardcode that it depends on the .dev. How do you manage it today, as you don't know if the stable or beta addon is installed, as they both have the same ID?
The skin will not be releasable in the Kodi repo until the dependent, improved, addon is itself released, at which point you point the dependency to the stable ID and test for regression.
If it's about a stable skin doing regression testing on a beta addon, then yes, I'm afraid you'll have to create a copy of the skin and change the ID's, which still makes much more sense than forcing the user to move to the beta addon without an easy rollback path and which could break a number of other skins/addons depending on it.
It's exactly the situation we want to prevent, actually