Bug#705565: Getting closure compiler back in testing?
On 12/30/2013 03:15 PM, gregor herrmann wrote: > On Mon, 30 Dec 2013 12:03:13 -0800, tony mancill wrote: > > The rename of the binary package from libclosure-compiler-java -> > closure-compiler should probably be done now as well to get this out of > the way well before the Jessie release. > >> It means that the "closure-compiler" binary package is merely the >> /usr/bin/ symlink and the dependency on jarwrapper. > > Can't this be solved with a simple > Provides: closure-compiler > in the libclosure-compiler-java package? > (Or the other way round.) > > Having a de facto empty package doesn't seem very appealing to me. Hi gregor, Yes, that will work, provided that no users of libclosure-compiler-java have concerns with jarwrapper (and its depdendencies, thus binfmt-support and fastjar) being pulled in when they only want the library. Given that all 3 packages are small, it's probably a non-issue. Thanks for the suggestion! tony signature.asc Description: OpenPGP digital signature
Bug#705565: Getting closure compiler back in testing?
On Mon, 30 Dec 2013 12:03:13 -0800, tony mancill wrote: > >>> The rename of the binary package from libclosure-compiler-java -> > >>> closure-compiler should probably be done now as well to get this out of > >>> the way well before the Jessie release. > It means that the "closure-compiler" binary package is merely the > /usr/bin/ symlink and the dependency on jarwrapper. Can't this be solved with a simple Provides: closure-compiler in the libclosure-compiler-java package? (Or the other way round.) Having a de facto empty package doesn't seem very appealing to me. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Bob Dylan: Temporary like Achilles signature.asc Description: Digital signature
Bug#705565: Getting closure compiler back in testing?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/12/13 21:03, tony mancill wrote: > On 12/30/2013 11:54 AM, Daniel Pocock wrote: >> >> >> On 30/12/13 20:35, Thomas Koch wrote: >>> On Monday, December 30, 2013 10:19:53 AM Daniel Pocock wrote: Tony made some commits in Git and it appears he is working to resolve this The rename of the binary package from libclosure-compiler-java -> closure-compiler should probably be done now as well to get this out of the way well before the Jessie release. I've made the changes for a rename on a branch called "pkgrename" and pushed that into Git Tony, are you making another upload shortly, would you like to merge pkgrename perhaps? >>> >>> closure compiler is also a library dependency, e.g. of gwt. It >>> might be a good idea to provide two binary packages, one for >>> the library jar and another one for the manpage + executable. >> >> That is awkward with an executable JAR, it is just a single >> artifact that can be used either way > > It means that the "closure-compiler" binary package is merely the > /usr/bin/ symlink and the dependency on jarwrapper. > > I don't know that it really matters much - the reason for the > rename is to make the binary package easier to find, but the > current java library package is named correctly (as per policy and > ease of locating) as well. > > I'm not sure if there is a best practice for executable JARs that > are used in both contexts, but adding an additional binary package > doesn't seem too bad. > - From a useability perspective, I agree that the two packages is more appealing I'll change my own packages to depend on closure-compiler when it exists I'd suggest doing the new binary package before doing the update to the latest code, then it will be easier for the FTP masters to review -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJSwdJ9AAoJEOm1uwJp1aqDFocP+wV2PFBQl4/4YBc/Hn/UJEhR wWhLJS8LlqHzqb3y+f5V/ezK55AYx/G0RWBSWxhsh9xmmOZFF4xqlF/k3wY2kjt4 YehjW8Px+Kn3VDLsb0Fyo6CSGk7N8rathGtcYbLIWDu2Qs/btlucPkdpk4Q8eoYM tf7eMs15tESNyVNkYGSbQ4Tltj1g6W/ZWlXxRnSPVBLSqUBqlXMoUcq/sFgsa/in OpSiszWakp99AMv6MubvM25kKKvlMzVhK9gf2OZ1I8JiX5dFiHw+/liRpRDDnFY+ mfNnvD58LNEvkVVV9xWCG3yVkj8uby8Zd3tBOn4MH2LuagUUUXdFL7neM2l+sSIi 04wua8i7nP0xyqc04Lxvkyt3Se6ro0Vsx6GKfXmR4kcoHjTmJGyWFTru4nPBd9QP 9Iqsk82Ym017nY181+NClgZZDmzxcR3xn8Lv29Adv4rYju4wOfoy6GGQUd2Iwyat 6OP3roxd03bOWXhIi83U72JWwCOxV00RVtLXfmWQFYD2Z6Yt5R4cCJXeZs8/sJZF sOpWWqadbGlUZViN0CJEuTIOBsZQFSt+hQxhNDMD0BFqgnybSkcmEg0j4USougNB lc5jOieLL9V3MoB/El5ht9dylzv9XK5vFG385U94YflxpVuV0MJ4cmyF4L1tRHSX yNzQjg+CE79snZpN8usR =BMiD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#705565: Getting closure compiler back in testing?
On 12/30/2013 11:54 AM, Daniel Pocock wrote: > > > On 30/12/13 20:35, Thomas Koch wrote: >> On Monday, December 30, 2013 10:19:53 AM Daniel Pocock wrote: >>> Tony made some commits in Git and it appears he is working to resolve this >>> >>> The rename of the binary package from libclosure-compiler-java -> >>> closure-compiler should probably be done now as well to get this out of >>> the way well before the Jessie release. >>> >>> I've made the changes for a rename on a branch called "pkgrename" and >>> pushed that into Git >>> >>> Tony, are you making another upload shortly, would you like to merge >>> pkgrename perhaps? >> >> closure compiler is also a library dependency, e.g. of gwt. It might be a >> good >> idea to provide two binary packages, one for the library jar and another one >> for the manpage + executable. > > That is awkward with an executable JAR, it is just a single artifact > that can be used either way It means that the "closure-compiler" binary package is merely the /usr/bin/ symlink and the dependency on jarwrapper. I don't know that it really matters much - the reason for the rename is to make the binary package easier to find, but the current java library package is named correctly (as per policy and ease of locating) as well. I'm not sure if there is a best practice for executable JARs that are used in both contexts, but adding an additional binary package doesn't seem too bad. tony signature.asc Description: OpenPGP digital signature
Bug#705565: Getting closure compiler back in testing?
On 12/30/2013 11:35 AM, Thomas Koch wrote: > On Monday, December 30, 2013 10:19:53 AM Daniel Pocock wrote: >> Tony made some commits in Git and it appears he is working to resolve this >> >> The rename of the binary package from libclosure-compiler-java -> >> closure-compiler should probably be done now as well to get this out of >> the way well before the Jessie release. >> >> I've made the changes for a rename on a branch called "pkgrename" and >> pushed that into Git >> >> Tony, are you making another upload shortly, would you like to merge >> pkgrename perhaps? > > closure compiler is also a library dependency, e.g. of gwt. It might be a > good > idea to provide two binary packages, one for the library jar and another one > for the manpage + executable. > > Regards, Thomas Koch Hi Thomas, Daniel, I agree with Thomas' suggestion. I'm not sure what the FTP team will think of the very small binary package (the next upload will go through NEW), but adding a binary package with just the manpage + JRE and jarwrapper dependency feels like the right thing to do. Any thoughts about whether it's better to update to a newer upstream and then rename, or rename first? Cheers, tony signature.asc Description: OpenPGP digital signature
Bug#705565: Getting closure compiler back in testing?
On 30/12/13 20:35, Thomas Koch wrote: > On Monday, December 30, 2013 10:19:53 AM Daniel Pocock wrote: >> Tony made some commits in Git and it appears he is working to resolve this >> >> The rename of the binary package from libclosure-compiler-java -> >> closure-compiler should probably be done now as well to get this out of >> the way well before the Jessie release. >> >> I've made the changes for a rename on a branch called "pkgrename" and >> pushed that into Git >> >> Tony, are you making another upload shortly, would you like to merge >> pkgrename perhaps? > > closure compiler is also a library dependency, e.g. of gwt. It might be a > good > idea to provide two binary packages, one for the library jar and another one > for the manpage + executable. That is awkward with an executable JAR, it is just a single artifact that can be used either way -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#705565: Getting closure compiler back in testing?
On Monday, December 30, 2013 10:19:53 AM Daniel Pocock wrote: > Tony made some commits in Git and it appears he is working to resolve this > > The rename of the binary package from libclosure-compiler-java -> > closure-compiler should probably be done now as well to get this out of > the way well before the Jessie release. > > I've made the changes for a rename on a branch called "pkgrename" and > pushed that into Git > > Tony, are you making another upload shortly, would you like to merge > pkgrename perhaps? closure compiler is also a library dependency, e.g. of gwt. It might be a good idea to provide two binary packages, one for the library jar and another one for the manpage + executable. Regards, Thomas Koch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#705565: Getting closure compiler back in testing?
On 30/12/13 00:48, Rogério Brito wrote: > Hi there. > > Can we have a late Christmas present (or even an New Year's present)? The > closure compiler: > > * has already been removed from testing [1] > * has many applications and users that depend/want it > * already has patches in the BTS [2] > > [1]: > http://packages.qa.debian.org/c/closure-compiler/news/20131229T163915Z.html > [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705565 > > Given this information, could we have something (even a NMU) to fix this? Tony made some commits in Git and it appears he is working to resolve this The rename of the binary package from libclosure-compiler-java -> closure-compiler should probably be done now as well to get this out of the way well before the Jessie release. I've made the changes for a rename on a branch called "pkgrename" and pushed that into Git Tony, are you making another upload shortly, would you like to merge pkgrename perhaps? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#705565: Getting closure compiler back in testing?
On 12/29/2013 03:48 PM, Rogério Brito wrote: > Hi there. > > Can we have a late Christmas present (or even an New Year's present)? The > closure compiler: > > * has already been removed from testing [1] > * has many applications and users that depend/want it > * already has patches in the BTS [2] > > [1]: > http://packages.qa.debian.org/c/closure-compiler/news/20131229T163915Z.html > [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705565 > > Given this information, could we have something (even a NMU) to fix this? > > > Thanks in the name of the users, Hi Rogério, I'll take a look to see if I can get the package building again. Thanks for pinging the list. Cheers, tony signature.asc Description: OpenPGP digital signature
Bug#705565: Getting closure compiler back in testing?
Hi there.
Can we have a late Christmas present (or even an New Year's present)? The
closure compiler:
* has already been removed from testing [1]
* has many applications and users that depend/want it
* already has patches in the BTS [2]
[1]: http://packages.qa.debian.org/c/closure-compiler/news/20131229T163915Z.html
[2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705565
Given this information, could we have something (even a NMU) to fix this?
Thanks in the name of the users,
Rogério.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
