Re: django-ajax-selects lintian errors/warnings
Neil Williams <codehelp@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 <bam@debian.org>
Reply to: