On Fri, Feb 26, 2016 at 07:59:29PM +0100, Jonas Smedegaard wrote: > Hi, > > Do we favor tracking the true upstreams when packaging for Debian? > > Concretely I need¹ a javascript library for server-side use, but the > maintainer considers it adequate² to package that project only > browser-optimized. > > I personally feel it is a bug to not track the true upstream of a > project, but that seems not part of our Policy. Should I respect fellow > package maintainers prioritizing convenience over elegance, or insist > that we should strive towards perfection? > > > - Jonas > > > ¹ I am initially packaging kss-node - bug#816003 > > ¹ bug#809977 requests adding node-handlebars to src:libjs-handlebars (to > cover not only browser but also server-side use), but package maintainer > chose to instead package libjs-handlebars from a Ruby bundling > (re)source (see changelog entry for ruby-handlebars-assets 2:0.20.1-3, > written some months after bug#809977).
In the case of this specific package, it seems there is come confusion. I found both src:libjs-handlebars _and_ src:ruby-handlebars-assets, with both providing libjs-handlebars binaries. If you recall, in Debconf we had a discussion between Ruby and Javascript teams, where we agreed that the right place for Javascript is the Javascript team, as proper javascript packages. IMO if that's not possible/pratical from the Ruby POV, at least the Ruby package should not invade the Javascript namespace, and the Javascript should be able to maintain the equivalent Javascript package The Right Way™. I think the issue needs to be communicated, this mess need to be cleaned up, and the correct technical decision needs to be implemented. If you care about the package, and about having it done right, I think you can just report bugs and write patches. I do not think there is any deliberate decision to hijack the Javascript package and not support your use case.
signature.asc
Description: PGP signature
