Re: howto handle jquery embedding by build-depends

[Helmut Grohne]

On Thu, May 08, 2014 at 11:45:24AM +0200, Thorsten Glaser wrote:
> This is a bug in doxygen. Replacing the embedded jquery copy
> in the Debian package shipping it with a link to the jquery
> version in Debian should be the right thing to do. Maybe this

Your criticism is unconstructive. I agree that this is wrong, but
sometimes wrong is the right thing to do. This is even acknowledged by
our policy which discourages embedded copies rather than forbidding
them.

I am not opposed to fixing this embedding, but I will not be doing the
work. I tried and figured that it is not worth the effort.  Apparently,
you didn't even read the reasons I gave for not fixing it. Otherwise you
might have given actual arguments.

> entire technology behind doxygen needs gentle kicking, like
> people such as Torsten Werner did to Java??? stuff, to get it to
> conform to our expectations.

Please stop useless ranting already.

For changing the status quo, your options are:
 * Explain what parts of the reasoning in Doxygen's README.jquery you
   consider wrong and why.
 * Provide patches that do not break existing use cases.
 * Maintain new packages that contain the Javascript libraries used by
   Doxygen.
 * Make Arch:all autobuilding work.

Helmut


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140512154022.ga16...@alf.mars

Re: howto handle jquery embedding by build-depends

[Russ Allbery]

Thorsten Glaser  writes:

> This is a bug in doxygen. Replacing the embedded jquery copy in the
> Debian package shipping it with a link to the jquery version in Debian
> should be the right thing to do.

This has previously been discussed on this list, and the Doxygen
maintainers said explicitly that this is *not* the right thing to do.
Apparently this isn't just a jQuery copy, but also contains other code or
other Doxygen-specific modifications.  (I've not investigated this myself;
just trying to act as institutional memory here.)

There was, at one point, some talk of a dh_doxygen helper that would do
the right thing, whatever that may be, but I don't think it's ever
materialized.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d2fo5moh@windlord.stanford.edu

Re: howto handle jquery embedding by build-depends

[Jonas Smedegaard]

Hi Vincent,

Quoting Vincent Bernat (2014-05-08 13:52:01)
> ❦  8 mai 2014 11:45 +0200, Thorsten Glaser  :
> 
>>> /usr/share/doc/doxygen/README.jquery
>>
>> This is a bug in doxygen. Replacing the embedded jquery copy in the 
>> Debian package shipping it with a link to the jquery version in 
>> Debian should be the right thing to do. Maybe this entire technology 
>> behind doxygen needs gentle kicking, like people such as Torsten 
>> Werner did to Java™ stuff, to get it to conform to our expectations.
>
> Yeah, let's ignore the others and say them they are wrong.
>
> In the JS world, they rely on "semantic versioning". In theory, this 
> says that version x.y+1.z is backward-compatible with x.y.w. In 
> practice, this is not always the case and automatic upgrade from one 
> minor version to another one should be done with care. jQuery is 
> mature enough to be more immune to this problem but many wide-used 
> libraries have this problem. For example, Twitter Bootstrap as in 
> Debian is 2.0.2 (quite old). The latest version for the 2.x serie is 
> 2.3. It is quite unlikely that a project using 2.0 can use 2.3 without 
> additional modifications.
>
> By forbidding embedded copies without providing a sensible alternative 
> (like a package with all minor versions of jQuery), we are just 
> introducing bugs in our packages making them of lesser quality.

You mention yourself that jQuery likely isn't as bad as e.g. Bootstrap, 
yet you describe only the extreme alternative of needing *all* versions 
of jQuery packaged.

I suggest that each package feeling the need for a specific version of 
jQuery (or any other JavaScript project) file a bugreport against 
corresponding package to get that version maintained properly.

Then we can revisit this issue in some months when we have a more 
realistic picture of a) how many versions of various code projects are 
really needed, and b) how maintainers of those code projects feel about 
maintaining code which is possibly abandoned and unmaintained upstream.

...and depending on b) we can then also discuss how maintainers of 
non-JavaScript packages expect to do a better job at maintaining such 
code - but let's first explore if possible for Debian to keep current 
separation of responsibility, before going down other paths.


> It is already difficult to make people understand how we work with our 
> release cycle. We don't need angry users and angry upstream because we 
> modify packages to introduce additional bugs.

Agreed.


> Like other languages, Javascript will mature and will handle those
> problems with their community. In the meantime, we need to be flexible
> and tolerant.

I think we can help JavaScript projects mature faster by tracking which 
projects comply with semantic versioning and which do not, instead of 
just assuming they don't comply.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: howto handle jquery embedding by build-depends

[Jose Luis Rivas]

On 08/05/14, 08:01am, Daniel Baumann wrote:
> src:lxc contains documentation (*.sgml only) and build-depends on
> docbook2x, no jquery is needed or installed as build-depends. the
> resulting bin:lxc-dev then contains a *compressed* jquery.js put there
> by docbook2x. lintian detects this and warns about it (W:
> embedded-javascript-library).
> 
> i think we have the following possibilities to handle such embedding of
> files by build-depends, where the embedded files were not part of the
> original source (starting with least favourable one):
> 
>   A: ignore it and overwrite the lintian warning
> 
>   B: overwrite the lintian warning, use a built-using: relation in
>  control (in lxc case, against docbook2x which imports the
>  jquery.js)
> 
>   C: post-process the binary package content at buildtime to replace
>  the embedded files through proper depends (e.g. for jquery,
>  replace the file with a symlink to /usr/share/javascript/jquery
>  /jquery.js and have a depends or recommends on libjs-jquery).
> 
>  this could potentially have side effects if the copy of the
>  to-be-embedded file (jquery.js) inside the tool that imports it
>  (docbook2x) is not in sync with the standalone packaged version
>  (libjs-jquery), so that we end up with a newer/incompatible
>  version.
> 
> for lxc, i'd go with C.
> 
> did i miss anything? (yes, i haven't fully read the last thread about
> jquery on debian-devel a couple of weeks ago, i think it only covered
> the 'what to do with embedded js in source packages'-cases, not this
> 'what to do with embedded js in binary packages not being part of the
> source package'-case).

I actually think there's a D option and is based on the solution that Daniel
Kahn Gillmor gave on a similar issue I had with powertop, which is using
native javascript instead of jquery. [0] Of course, this wouldn't be on
lxc but directly on docbook2x and that would fix it for more packages
than only lxc.

[0] https://bugs.debian.org/695890

Other people in this thread has already pointed out the issues with
several versions of jQuery and I honestly believe native javascript
should be enough for the transformations docbook2x seems to be using.

BTW, I failed to see on docbook2x website how is that javascript is used
at all. Would you give me a hint so I don't need to build the package
myself to check if this is actually a viable solution in this case as
well?

Kind regards.
-- 
Jose Luis Rivas | ghostbar
The Debian Project → 
GPG 3E7D 4267 AFD5 2407 2A37 20AC 38A0 AD5B CACA B118


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140508130217.gb1...@arya.ghostbar.co

Re: howto handle jquery embedding by build-depends

[Vincent Bernat]

 ❦  8 mai 2014 11:45 +0200, Thorsten Glaser  :

>> /usr/share/doc/doxygen/README.jquery
>
> This is a bug in doxygen. Replacing the embedded jquery copy
> in the Debian package shipping it with a link to the jquery
> version in Debian should be the right thing to do. Maybe this
> entire technology behind doxygen needs gentle kicking, like
> people such as Torsten Werner did to Java™ stuff, to get it to
> conform to our expectations.

Yeah, let's ignore the others and say them they are wrong.

In the JS world, they rely on "semantic versioning". In theory, this
says that version x.y+1.z is backward-compatible with x.y.w. In
practice, this is not always the case and automatic upgrade from one
minor version to another one should be done with care. jQuery is mature
enough to be more immune to this problem but many wide-used libraries
have this problem. For example, Twitter Bootstrap as in Debian is 2.0.2
(quite old). The latest version for the 2.x serie is 2.3. It is quite
unlikely that a project using 2.0 can use 2.3 without additional
modifications.

By forbidding embedded copies without providing a sensible alternative
(like a package with all minor versions of jQuery), we are just
introducing bugs in our packages making them of lesser quality.

It is already difficult to make people understand how we work with our
release cycle. We don't need angry users and angry upstream because we
modify packages to introduce additional bugs.

Like other languages, Javascript will mature and will handle those
problems with their community. In the meantime, we need to be flexible
and tolerant.
-- 
Parenthesise to avoid ambiguity.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: howto handle jquery embedding by build-depends

[Thorsten Glaser]

On Thu, 8 May 2014, Paul Wise wrote:

> /usr/share/doc/doxygen/README.jquery

This is a bug in doxygen. Replacing the embedded jquery copy
in the Debian package shipping it with a link to the jquery
version in Debian should be the right thing to do. Maybe this
entire technology behind doxygen needs gentle kicking, like
people such as Torsten Werner did to Java™ stuff, to get it to
conform to our expectations.

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.10.1405081143450.20...@tglase.lan.tarent.de

Re: howto handle jquery embedding by build-depends

[Paul Wise]

On Thu, May 8, 2014 at 2:43 PM, Paul Wise wrote:

> You may have missed the maintainer's take on this:
>
> /usr/share/doc/doxygen/README.jquery
> http://sources.debian.net/src/doxygen/1.8.6-2/debian/README.jquery

Woops, I confused doxygen with docbook2x. The situation sounds similar though.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6gjoe2rw55j4_gd2blc+6nxoou4qxafetswj1fknmt...@mail.gmail.com

Re: howto handle jquery embedding by build-depends

[Paul Wise]

On Thu, May 8, 2014 at 2:01 PM, Daniel Baumann wrote:

> did i miss anything?

You may have missed the maintainer's take on this:

/usr/share/doc/doxygen/README.jquery
http://sources.debian.net/src/doxygen/1.8.6-2/debian/README.jquery

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6fuljmtk14egtjjcnxtaqpdjb_xewh3fzhgzyzjyca...@mail.gmail.com

howto handle jquery embedding by build-depends

[Daniel Baumann]

src:lxc contains documentation (*.sgml only) and build-depends on
docbook2x, no jquery is needed or installed as build-depends. the
resulting bin:lxc-dev then contains a *compressed* jquery.js put there
by docbook2x. lintian detects this and warns about it (W:
embedded-javascript-library).

i think we have the following possibilities to handle such embedding of
files by build-depends, where the embedded files were not part of the
original source (starting with least favourable one):

  A: ignore it and overwrite the lintian warning

  B: overwrite the lintian warning, use a built-using: relation in
 control (in lxc case, against docbook2x which imports the
 jquery.js)

  C: post-process the binary package content at buildtime to replace
 the embedded files through proper depends (e.g. for jquery,
 replace the file with a symlink to /usr/share/javascript/jquery
 /jquery.js and have a depends or recommends on libjs-jquery).

 this could potentially have side effects if the copy of the
 to-be-embedded file (jquery.js) inside the tool that imports it
 (docbook2x) is not in sync with the standalone packaged version
 (libjs-jquery), so that we end up with a newer/incompatible
 version.

for lxc, i'd go with C.

did i miss anything? (yes, i haven't fully read the last thread about
jquery on debian-devel a couple of weeks ago, i think it only covered
the 'what to do with embedded js in source packages'-cases, not this
'what to do with embedded js in binary packages not being part of the
source package'-case).

-- 
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:  daniel.baum...@progress-technologies.net
Internet:   http://people.progress-technologies.net/~daniel.baumann/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/536b1db1.10...@progress-technologies.net