On Thu, 14 Aug 2014, Thomas Goirand wrote: > Just a quick explanation of what I'm doing with the python-xstatic-* > packages here. I've thought about how to do it best for a long time.
Thanks! I was wondering. > It is also worth noting that the Debian package version for XStatic > modules is following the static file package version. For example, even > though upstream released XStatic-JQuery 1.10.2.1, the Debian package > version is 1.7.2.0, to match the version number of libjs-jquery. Idea here: can’t python-xstatic-jquery just take over libjs-jquery via Provides, so we have one binary package less after this? (Of course, if the Debian JS maintainers agree, and probably will want to (co-)maintain python-xstatic-jquery after this.) Similar for the other ones. That would mean we’d have almost zero cost for the addi‐ tion of python-xstatic-* because they’d just take over the non-xstatic ones and provide the same functionality plus more. > My only concern with all of this, is that it will produce a lot of > micro-packages. Though I believe the benefits of having a clean system > to remove embedded copies and having a clean way to find these files on > a Debian system outweighs the added load on our infrastructure. Right… which is why I suggested the above ;-) As for micro packages in general… I’d say the goal here is to remove code duplication, so packaging things like this is useful, but if there are several micro packages with the same dependencies, they could be grouped into one binary package, for example this was done in src:mediawiki-extensions which produces mediawiki-extensions-base for all those with no additional dependencies, and then several small packages that contain only one or two extensions each, which share some additional dependencies like PHP modules, graphviz, etc. Since we can have versioned Provides soon, I believe this could be used by most of the JS packages. A binary package libjs-jquery-bundle which Provides all the others with versions. This would leave us with the maintainer burden because it has multiple upstreams with different versions. Simply adding the version numbers will not always sort well, either… but I think that the overall load (maintainers + infrastructure + mirrors + users) will be the lowest like that. bye, //mirabilos PS: [OT] A coworker just shared this in our MUC: https://lh3.googleusercontent.com/-bZId5j2jREQ/U-vlysklvCI/AAAAAAAACrA/B4JggkVJi38/w426-h284/bd0fb252416206158627fb0b1bff9b4779dca13f.gif -- [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.11.1408140934140.30...@tglase.lan.tarent.de
