[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Uploading python-xstatic-* packages in Debian

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, the Debian package
> version is, 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.


PS: [OT] A coworker just shared this in our MUC:
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...

Reply to: