+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Add-ons (https://forum.kodi.tv/forumdisplay.php?fid=26)
+--- Thread: Bug Repository XML Bug in Jarvis-Beta3? (/showthread.php?tid=251420)
Pages:
1
2
Repository XML Bug in Jarvis-Beta3? - tknorris - 2015-12-09
I have a repository with a addons.xml structured as follows:
Code:
<extension point="xbmc.addon.repository" name="repository">
<dir>
<info compressed="false">source 1/addons.xml</info>
<checksum>source1/addons.xml.md5</checksum>
<datadir zip="true">source1</datadir>
</dir>
<dir>
<info compressed="false">source2/addons.xml</info>
<checksum>source2/addons.xml.md5</checksum>
<datadir zip="true">source2</datadir>
</dir>
<info compressed="false">source3/addons.xml</info>
<checksum>source3/addons.xml.md5</checksum>
<datadir zip="true">source3</datadir>
</extension>Some addons in source1 may not be in source2 and/or source3. This addons.xml structure worked fine in Helix and Isengard but Jarvis Beta-3 Kodi is attempting to download addons found in source 1 from source 3.
Is this an intentional change to require all sources in the addons.xml have the same addons in it or is it a bug?
I can share a log of the issue but it will contain banned addons.
RE: Repository XML Bug in Jarvis-Beta3? - ironic_monkey - 2015-12-10
bug bug. you are using the layering exactly as it is intended to work.
RE: Repository XML Bug in Jarvis-Beta3? - tknorris - 2015-12-10
Yeah, I thought so, but I thought maybe layering was being removed from Jarvis or something. I noticed the Jarvis repo has all the addons from all Kodi releases lumped into it and the addon.xml for the official repo for Jarvis is no longer using multiple <dir> elements....It would be nice if someone can let me know before Jarvis is released if this is intentional since my repo xml's will need to be updated if so...
RE: Repository XML Bug in Jarvis-Beta3? - takoi - 2015-12-10
Not intentional. Will be fixed for Jarvis, but for K** this feature will most likely be removed, so you should prepared for moving to a single directory then.
RE: Repository XML Bug in Jarvis-Beta3? - Martijn - 2015-12-10
Why? This I a really good feature for addon developers so they don't have to provide several repos.
RE: Repository XML Bug in Jarvis-Beta3? - tknorris - 2015-12-10
(2015-12-10, 21:10)Martijn Wrote: Why? This I a really good feature for addon developers so they don't have to provide several repos.
Yes, I agree.
In this use case we use Source 1 as a common set of modules that are used in several addons developed by several different addon developers. Each developer just includes that first <dir></dir> element in their repository xml to allows user's of their repositories to pick up updates to those common modules.
I also thought that the <dir> element was to be used to allow for some addons to be updated for API changes in in Kodi versions while still allowing an older version of the addon to exist for older, incompatible versions of the API?
RE: Repository XML Bug in Jarvis-Beta3? - ironic_monkey - 2015-12-11
yes, that's why it was added. and so you don't have to stick all addons in all repos. like it is now - (most) plugins are compatible back to gotham so they all sit only in the gotham repo. removing this would be pure stupid.
RE: Repository XML Bug in Jarvis-Beta3? - takoi - 2015-12-11
(2015-12-10, 21:10)Martijn Wrote: Why? This I a really good feature for addon developers so they don't have to provide several repos.Cruft. The feature's been a mistake from the beginning. It's poorly done and bog down the whole repository code (as we have just witnessed) making it difficult to maintain and to add new features. It's not even a good feature. It increases traffic and slows down repository updates for users only for a minor convenience for repository owner.
(2015-12-10, 21:16)tknorris Wrote: I also thought that the <dir> element was to be used to allow for some addons to be updated for API changes in in Kodi versions while still allowing an older version of the addon to exist for older, incompatible versions of the API?Simply create a new repository location and update the repository addon to use that as we currently do with the official repository. It might take you some one time effort to set that up, but in the long run you'll benefit from doing it this way.
RE: Repository XML Bug in Jarvis-Beta3? - tknorris - 2015-12-11
(2015-12-11, 14:21)takoi Wrote: Simply create a new repository location and update the repository addon to use that as we currently do with the official repository. It might take you some one time effort to set that up, but in the long run you'll benefit from doing it this way.
You are solving the wrong problem. The use case we use this for is common shared addons, not incompatible versions. Each addon developer adds that dir element to point to Source1 and therefore their addons can be installed with references to these common modules and as those modules get updated, their uses automatically get updates. I don't see any way to easily solve that problem if you remove the <dir> elements.
RE: Repository XML Bug in Jarvis-Beta3? - takoi - 2015-12-11
(2015-12-11, 17:58)tknorris Wrote: You are solving the wrong problem. The use case we use this for is common shared addons, not incompatible versions. Each addon developer adds that dir element to point to Source1 and therefore their addons can be installed with references to these common modules and as those modules get updated, their uses automatically get updates. I don't see any way to easily solve that problem if you remove the <dir> elements.This is different from using a single directory how?
RE: Repository XML Bug in Jarvis-Beta3? - tknorris - 2015-12-11
(2015-12-11, 18:23)takoi Wrote:(2015-12-11, 17:58)tknorris Wrote: You are solving the wrong problem. The use case we use this for is common shared addons, not incompatible versions. Each addon developer adds that dir element to point to Source1 and therefore their addons can be installed with references to these common modules and as those modules get updated, their uses automatically get updates. I don't see any way to easily solve that problem if you remove the <dir> elements.This is different from using a single directory how?
Either I'm not understanding your question or you aren't understanding mine. How would different developers all with different repositories of their own share a common set of modules with a single directory?
RE: Repository XML Bug in Jarvis-Beta3? - takoi - 2015-12-11
(2015-12-11, 18:25)tknorris Wrote:I'm definitely not understanding yours. Why would developers all add this 'shared repository' as a directory of their repository?(2015-12-11, 18:23)takoi Wrote:(2015-12-11, 17:58)tknorris Wrote: You are solving the wrong problem. The use case we use this for is common shared addons, not incompatible versions. Each addon developer adds that dir element to point to Source1 and therefore their addons can be installed with references to these common modules and as those modules get updated, their uses automatically get updates. I don't see any way to easily solve that problem if you remove the <dir> elements.This is different from using a single directory how?
Either I'm not understanding your question or you aren't understanding mine. How would different developers all with different repositories of their own share a common set of modules with a single directory?
Simply have a separate repository for these modules (it's already "shared" and can be used by everyone else by default). Or you pull in all these modules to their own behind the scene creating one directory, containing both yours addons and a copy of the 'shared' ones (no idea why you would want to do that though).
RE: Repository XML Bug in Jarvis-Beta3? - tknorris - 2015-12-11
(2015-12-11, 18:23)takoi Wrote: Simply have a separate repository for these modules (it's already "shared" and can be used by everyone else by default). Or you pull in all these modules to their own behind the scene creating one directory, containing both yours addons and a copy of the 'shared' ones (no idea why you would want to do that though).
Your solution to the use case is basically "Don't do that". The only way to "share" a repository as you suggested is with the <dir> element. Your other solution doesn't work at all because each developer maintains their own repo and they would have to update their repo everytime one of of those common modules was updated. Sometimes these modules are updated multiple time per week. As it is now, one developer maintains the common repo and all the other developers benefit from it as long as they include the Source1 <dir> element.
It seems like you are intent on dismissing any use case that doesn't meet your pre-determined desire to get rid of this function. Given that, there's probably no point in continuing to go back and forth on this. If you guys ultimately decide to remove this from K** it would be helpful for us for you to announce it in advance so that we can adjust our repositories accordingly.
RE: Repository XML Bug in Jarvis-Beta3? - takoi - 2015-12-11
I'm simply trying to understand if there are any actual uses for it. You said something is not possible to do with a single, but not explaining well what, nor what the use case is. "The only way to "share" a repository as you suggested is with the <dir> element." Again this doesn't make any sense because it is perfectly possible to share modules across repositories without "including" it in any way. If it isn't it's a bug.
Alternatively, we are talking about completely different things..
RE: Repository XML Bug in Jarvis-Beta3? - tknorris - 2015-12-11
I really can't think of a way to explain it other than how I already have:
Dev A maintains common module B and updates it frequently (weekly+)
Dev C develops addon D using common module B.
Dev C wants to include all changes made to common module B by Dev A on an ongoing basis to users of addon D.
If you lump both B and D into a common repo/directory, then both A and C need the ability to update that one repository. That quickly becomes an issue when you are talking more than 2 people. Not only that, but A now has to update B in every repository it's in rather than one time in the common repository.
If C copies common module B into their repository, then they have to continue to do that every time B is updated. Again, this quickly becomes an issue when talking about more than 2 people.
The only solution is for Dev C's repository to somehow reference the common repository that B is in. If you guys want to provide some other solution, then so be it, but at the moment, the only way to do that is with the <dir> element.
There are other use cases as well for the <dir> element but I'll avoid mentioning them to keep on topic.
Edit: I just realized I should have added that if you want to say "That's not a use case we care about, find another solution" then I suppose that's a valid response as well.