On Sun, Jan 05, 2014 at 09:51:38PM +0100, Miro Hrončok wrote:
I would like to package OctoPrint , a webapp that host 3D printers.
I started with building a (somehow) working package in Copr .
This package probably doesn't follow FHS and violates other
guidelines as well, but that's not the issue right now.
What bothers me, if I want OctoPrint in Fedora (and I do) is
bundling. Currently, upstream OctoPrint bundles a lot of stuff :
* Twitter Bootstrap
* jQuery stuff
* SockJS client
* Font Awesome
I've never packaged a webapp into Fedora but I think that all the
standard rules like no bundled libraries apply here as well.
So the situation here is:
1) bootstrap and jquery are packaged in Fedora as rubygems while
OctoPrint is witten in Python. I'm not really into shiping all Ruby
(and Rails) only to have bootstrap and jquery. Not to mention that
the version in those rubygems is probably not the same as in
The rubygems need to unbundle those as well.
of packages that will need to unbundle things that they were bundling under
the status quo from before.
There could be separate packages for the different unbundled versions.
Might want to touch base with patches (TC Hollingsworth) to see if there's
some master plan for some of these.
2) underscore.js is packaged as nodejs package and we have the same
problem (if the thing in package is the same thing as in OctoPrint at
Might want to talk to patches about this one. I know this was considered in
method was intended to mitigate it.
3) AVLTree is not in Fedora at all, but the js file in OCtoPRint is
different form "uspream" - single js. file on gist.github.com
Yeah -- this is likely to be an issue just like with other bundled
libraries. The first step is to find out what the changes are and if
they're acceptable to upstream for the library.
4) Knockout is not in Fedora, but upstream version  is one year
front of what is bundled in OctoPrint. Modernizr is not packaged and
upstream version is ahead as well.
Traditionally, Fedora works to port software to newer versions of their
dependencies. That contributes to upstream and also helps to keep the
number of packages smaller.
We *can* also package separate versions of the libraries into separate
packages as well but that can be more work in the long term so it's usually
preferable to port instead.
5) LESS is packaged as nodejs package and pull nodejs with it. Also,
completely different version than in OctoPrint
I think this might have been addressed in the above notes.
6) We do have python-sockjs-tornado in Fedora, witch is a dependency
of OctoPrint as well, but I see no client packaged. However, the
latest upstream version is in OctoPrint.
So this might be a packaging RFE for python-sockjs-tornado?
7) Font Awesome is being reviewed , but exist as texlive- package
texlive should unbundle Font Awesome after the new package has been added to
While I'm probably able to package all unpackaged bundles in
and deal with different versions communicating with upstream, I'm not
quite sure with all stuff that's depending on Node.js, TeX or Ruby. I
don't want this Python app to pull all this.
It shouldn't need to pull those things. The present situation for those
deps is probably due to bundling being tacitly allowed for web assets in the
problem should hopefully fade.
separately). I know that patches was looking at knocking out some things en
masse (for instance, jquery was on his radar because it is bundled with many
instances of python module documentation). He might have some helpful ideas
for some of this.