I apply for permission to bundle the trml2pdf sources in openerp-server, despite that there is a python-trml2pdf package.
Some background, as I understand it: trml2pdf was a project started by TinyERP, the same company as current OpenERP (OE). The source has since been part of the OpenERP server, and has also evolved over time. Currently it's not maintained as a separate project, it's just a directory in a big source tree.
At some point the satchmo project bundled a nowadays old version 1.2 with their project. In an attempt to package satchmo trml2pdf was packaged as a dependency, based on this source.
Now, some year later I have submitted a request for openerp-server .I want of course to use the system's python-trml2pdf, but it then need to be patched to current OE status, in some ways representing the "upstream". The patch is about 2000 lines. The maintainer hesitates to accept this patch, since it will make unusable in satchmo - the very reason he packaged it.
It's worth mentioning that no package today uses python-trml2pdf.
Should Cristian, the maintainer, accept the patch this request can be dropped. OTOH, he will then be forced to apply for an exception for an upcoming satchmo package. If he rejects the patch, I see no other viable option than to bundle trml2pdf in OE.
The standard questions: - The library has been heavily modified, as obvious from a 2000 lines patch. - The patch can't really be pushed to upstream, it rather represents the upstream. - The old code used by satchmo/python-trml2pdf can partly be explained by OE not maintaining a separate project - The changes has been proposed to fedora maintainer in BZ 818990. This is still an open issue, which I hope someone from fpc can participate in. - The OE version could certainly become the Fedora version, by mixing the boilerplate python module code from current fedora version with OE updates; basically by accepting the patch. - I'm unsure about the usefullnes for others, current python-trml2pdf has been in repo for some time without being used by anyone. - Current upstream does not maintain trml2pdf at all (?). OE maintains the code, but not as a separate project - Upstream's attitude is unclear, as well as what the upstream really is. - This is code converting rml to pdf - I see no specific security concerns. - I have discussed the situation in email with the maintainer, and after that opened BZ 818990. Basically I think we are both confused by the situation. However, it's confirmed that satchmo doesn't work with the patch. - As long as the Fedora package is based in older code than OE's current one I see no reasonable plan to unbundle current trml2pdf in OE. Maintainer has mentioned discussion on satchmo mailing list about dropping trml2pdf, but without conclusions.
Links: Satchmo project: http://www.satchmoproject.com/ openerp-server review request: https://bugzilla.redhat.com/show_bug.cgi?id=817271 request to patch current python-trml2pdf: https://bugzilla.redhat.com/show_bug.cgi?id=818990 openerp-server code at launchpad: http://bazaar.launchpad.net/~openerp/openobject-server/trunk/files
Setting correct component.
I must stress that when I ask Cristian to accept the patch I put him in an awkward situation. One one hand he doesn't want to block the OE packaging, on the other he want to be able to package satchmo.
The more I think about this, I feel that a bundling exception is the right way. This will make OE use the actual, maintained source without messing with the outdated v1.2 bundled in satchmo and in currrent fedpora package. It will also resolve the situation for Cristian..
Cristian is on travel since Friday, disconnected, so it might take some time before we get his view.
Arguably, the right way is to port satchmo to use the newer python-trml2pdf API but the fact that OpenERP is no longer maintaining a separate trml2pdf may make a different decision viable.
Exactly. In other words, the problem is the existing python-trml2pdf package based on old, bundled sources. OE does nothing odd here, they just have sources they once wrote and now maintain i. e., without current trml2pdf package there would have been nothing to discuss.
But since the package does exist, OE needs a bundling exception to include their own project. Quite a situation, isn't it ;)
The existing python-trml2pdf package must either be renamed to python-trml2pdf12 or retired. FPC asks the openERP maintainer to consider making a python-trml2pdf subpackage (placed in the proper python site-packages path), but is not required to do so. (+1:6, 0:1, -1:0)
This also means that OE is okay to include their python-trml2pdf code.
I've just returned and as I've already said to leamas, I'll test Satchmo with the new trml2pdf. If it doesn't work and it takes too long to fix Satchmo, I'll rename my package.
+1 for a python-trml2pdf subpackage provided by openERP
P.S. The trml2pdf provided by OpenERP is too tightly coupled with OpenERP, so I can't use for the moment. I have filled a [https://bugzilla.redhat.com/show_bug.cgi?id=821455 re-review for the renaming from python-trml2pdf to python-trml2pdf12].
Login to comment on this ticket.