The new version of slic3r (1.0.0RC1) bundles admesh.

Slic3r is a tool to generate GCODE for 3D printers from STL and other forms of triangular mesh.

Admesh is a triangular mesh analyzer and repairing tool.

While admesh originated as a command line utility (no library) in 1996 [0], it has been recently discovered by 3D printing community and it has been bundled to at least two projects I know about.

First of them, simarrange [1] has recently been approved for Fedora [2] and needed no bundling exception as I've been able to take admesh, make it a library and backport all changes from simarrange project [3]. Together with maintainer of admesh package we decided that using "my" admesh in Fedora is OK, as the command line utility from 1996 still works [4]. I've also convinced upstream of simarrange to use that lib in the future (no link, IRC).

However, the second project that bundles admesh is slic3r. I worry the changes made on slic3r side would break the functionality of both admesh tool itself and simarrange as well. I'm slowly and carefully trying to accept slic3r's changes and don't break anything.

Upstream has no will to unbundle admesh from various reasons [5].

Now I would really like to see new version of slic3r in Fedora 20, as 3D printing form the software perspective is very beading edge and having old version of slic3r in Fedora would mean that everyone would try to install the new version somehow anyway.

I guess I'm not able to unbundle admesh properly so I ask for '''temporary bundling exception''' until I solve this. Or until I decide that it is not possible and then we can discuss a long term exception.

'''Has the library behaviour been modified?'''

Yes it was.

'''How has it been modified?'''

There are bugfixes, those are OK and I merge them to admesh easily. But there are also API changes and certain functions/methods changes their meaning (for example translate changes from absolute to relative).

'''Why haven't the changes been pushed to the upstream library?'''

Original upstream of admesh is dead. I've taken the responsibility to be the new upstream but upstream of slic3r sees no point in doing so, so that's up to me. I try hard, but some of the changes are defective for admesh itself and for other projects depending on it (simarrange).

'''Have the changes been proposed to the Fedora package maintainer for the library?'''

I haven't talked about this with John C Peterson (CCed), but I would rather see the changes merged to "my" new upstream than to Fedora package only. Now in this moment Fedora is the only distro that uses that upstream anyway so it would hardly make any difference, other than maintaining patches in Fedora.

'''Could we make the forked version the canonical version within Fedora?'''

Nope. The forked version dropped the command line utility admesh in the first place. Other reasons have been already written in previous answers.

'''Are the changes useful to consumers other than the bundling application?'''

Most of them are.

'''If so why aren't we proposing that the library be released as a fork of the upstream library?'''

Upstream of slic3r has zero interest of this. So it would then be me again maintaining two different versions of admesh.

'''Is upstream keeping the base library updated or are they continuously one or more versions behind the latest upstream release?'''

Last version of original admesh was released in 1996.

'''What is the attitude of upstream towards bundling?'''

Cite: ''To be honest, I'm reluctant on this. I don't like to depend on an external library which is poorly maintained (no offense) and lacks a testing suite to prevent regressions from people committing to its repository. The admesh code is so critical for Slic3r now, so I need to be able to fix bugs and change things on the fly should an issue arise. This is also why I removed the dependency on Boost.Geometry.''

''I'd say the compliancy with any distribution-specific packaging policy needs to be addressed at the packaging level rather than the upstream level. Why don't you just take a diff between my admesh and your distribution's admesh and check whether my patches are applicable? If they are, you can just link Slic3r to the library. If they aren't, you have a good reason for requesting an exception.''

''Also note that admesh is not a library. It's a command line utility. No API call is documented, and it wasn't designed to be a library. I took some code out of it and adapted it to Slic3r. So I think it's not entirely correct to consider it a library and apply the unbundling policies.''

'''Overview of the security ramifications of bundling'''

I guess no security at all.

'''Does the maintainer of the Fedora package of the library being bundled have any comments about this?'''

He's CCed.

'''Is there a plan for unbundling the library at a later time?'''

I plan to work on this but due to lack of time I am not able to make it before Fedora 20 is out. I'm sure that before F21 I will be able to either unbundle this or definitely say it's not possible.

Thanks a lot and keep me posted.

[0] http://www.varlog.com/admesh-htm

[1] https://github.com/kliment/simarrange

[2] https://bugzilla.redhat.com/show_bug.cgi?id=1021919

[3] https://github.com/hroncok/admesh

[4] https://bugzilla.redhat.com/show_bug.cgi?id=1008284#c7

[5] https://github.com/alexrj/Slic3r/issues/1525#issuecomment-29157579