Neil Williams <codeh...@debian.org> writes: >> E: django-ajax-selects source: source-is-missing >> ajax_select/static/ajax_select/js/bootstrap.js > > If this really is your own source code, a filename change would be one > way to do it. In most cases, bootstrap is not written by this upstream > but has been included into the upstream VCS from another location.
No, I have another package with bootstrap.js and lintian has no problems. Suspect it might be due to line length. There are several bug reports on this, the one I can find is: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802028 >> python3-ajax-select: image-file-in-usr-lib >> usr/lib/python3/dist-packages/ajax_select/static/ajax_select/images/loading-indicator.gif > > This matters more when the package list from this source package > contains Architecture: any instead of Architecture: all binaries, which > is uncommon with django apps. With Arch: any, the files in /usr/lib/ > would be duplicated for each arch build which is a clear problem to be > avoided. This is Architecture: all, so sounds like not a problem here. >> E: python3-ajax-select: privacy-breach-uses-embedded-file >> usr/lib/python3/dist-packages/ajax_select/static/ajax_select/js/bootstrap.js >> You may use libjs-jquery-ui package. > > You may indeed - replace the file with a symlink in debian/rules and > add to Depends. Replace what file with a symlink? bootstrap.js isn't the problem itself, the problem is bootstrap.js referencing jquery.min.js from an external source. The library itself doesn't currently come with a copy of jquery. In this case the python*-ajax-select packages are not intended to be used by users, rather they are libraries intended to be used by other applications (Django apps) which are used by users. There simply isn't a single standard way I know of providing and using one and only one jquery in Django libraries. (no - Django Media objects don't help) Maybe I should raise this issue with the Django developers? Even if I did, came up with a proposal (I don't have one), and we agreed to a solution, we still need a solution for now, with the current release of Django. If I tell upstream to include a copy of jquery.min.js and/or jquery.js in the static directory (this is another issue[1]), it will get exported in all Django apps that use this library, including those that don't need or want it. Maybe this is considered a reasonable tradeoff - it is unlikely to cause conflicts due to the directory name used, however I come from the school of thought that you shouldn't be publishing files unless there actually is a need to publish the files. Apologies if I seem argumentative, however I really don't see a good solution to this. The best decision really depends on the Django app that uses this library, and upstream have tried to make it easier to get started using the library in such a way it has minimal downsides for Django apps that want to include their own version of jquery. >> privacy-breach-uses-embedded-file - this is only correct if used by an >> application that does not import jquery symbols itself. If the >> application already has loaded jqueblry and jquery-ui from, say a >> local source, I believe there is no privacy issue: >> >> // load jquery and jquery-ui if needed >> // into window.jQuery >> if (typeof window.jQuery === 'undefined') { >> document.write('<script type="text/javascript" >> src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"><\/script><script > > That src can be patched to not look at //googleapis but to look at > {{ STATIC }}/blah/js/jquery.min.js which itself is a symlink. Similarly > with href. Work with upstream about the problems of relying on third > party sites for their code. Like I said above, that means upstream must provide jquery.min.js, and presumably we need a way to automatically build jquery.min.js from jquery.js. Seems a lot of work for something may get overriden and not used by the calling application anyway... (actually this could be considered a poor example, doesn't appear that anything in Debian depends on this package, and my outside-Debian packages that were using it are dead or dying - however have seen similar issues in other packages). Notes: [1] I guess upstream would need to include jquery.js and then build jquery.min.js in setup.py or something; not sure how you would do this actually, especially if you want to retain the ability to test the code from the source directory. -- Brian May <b...@debian.org>
