Hi Antonio, Quoting Antonio Terceiro (2016-02-26 21:47:03) > On Fri, Feb 26, 2016 at 07:59:29PM +0100, Jonas Smedegaard wrote: >> 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? NB! I deliberately try to ask a more general question above, only triggered by a concrete case, mentioned to illustrate the kind of problem I am talking about: Solving the concrete case is nice but does not really address the general question. >> ¹ 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. For unstable both source packages provide same binary package, yes, but only one of the source packages are in stable and only the other is in testing, so nothing is broken about it - but indeed confusing to follow. > 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. I do recall our conversation at Debconf. That was however, I believe, an agreement only between teams. I believe we cannot impose team rules on Debian as a whole: I can file a _whishlist_ bugreport against a package requesting it to follow team rules, but not raise severity based on team rules, I believe. What I try ask here is the general logic - not just how to untangle the concrete issue. What is "the correct technical decision"? No, I don't think there is evil intention - but judged by the changelog message alone it seems to me that there is a deliberate choice on using the "wrong" upstream for the binary package. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature