libArcus.so SONAME and .so.VERSION don't match

[onitake]

When building libArcus 2.1.3, the SONAME gets (correctly) set to libArcus.so.2, but the library itself is named libArcus.so.1.0.0.
While this inconsistency does not cause any immediate problems, it's a bad idea and should be fixed.

This line:
set(ARCUS_VERSION 1.0.0)
should read:
set(ARCUS_VERSION 2.1.3)

[thopiekar]

I remember there was a discussion about this already in the past. The reason is as far as I remember that libArcus has actually it's own version/API. We only tag it with the same version as Cura because it is the only software at the moment which uses it.
So in theory you are right, but practically we "don't care"(?).

[onitake]

I don't really mind myself, but there may be confusion or even breakage around this.

In particular, I am currently in the process of preparing Debian packages of all the Cura components, and the dependencies should be "correct" there. A library version that falls outside the schema (i.e. package version != library version) could confuse people.

But I'll have to consult with some Debian maintainers first.

[thopiekar]

Hope you don't forget that there are already packaging files around. Mit freundlichen Grüßen/With kind regards - Thomas Karl Pietrowski

[onitake]

There are?
Aside from the cmake/cpack scripts and setup.py for Windows, I didn't see anything.
Can you point me in the right direction?

[thopiekar]

I currently maintain a Ubuntu PPA and you can find all packaging files at thopiekar/Cura-packaging 😉

[onitake]

I see.
Looks good to me, though I noticed some things:

• cura-engine will probably conflict with the legacy cura-engine in Debian, because of the changed versioning scheme. I'm not sure if the added epoch will work around this.
• Your builds depend on dh-python, but that has caused dh to try and build python2 and python3 packages in my case. Have you found a way around that? I found that dh-python is not really necessary, since cmake is used.

[thopiekar]

• Not only because of the version scheme, but by the usage of ini and json files for machine definitions.
• I always use dh_make to create initial packaging files. Looks like dh_make detected setup.py and thought the project uses it by default. Using CMake here is correct of course.

You can open issues there if you like and, if there are improvements, feel free to send PR's 😉
The only rule I have is: Just make changes on the master directory. The idea is to copy master on every new release to 2.x and remove the old-stable directory.

(The discussion about the packaging files is off-topic here 😉 )

[awhiemstra]

@onitake As far as I know, there should be no problems if you create a separate package for libArcus. Debian already splits up a lot of things (including things I find really inconvenient like QtQuick plugins). Of course, the maintenance burden might be higher, but libArcus does not see that much change, one of the reasons I want to decouple it from Cura.

[onitake]

Re-reported as #52 - there is more technical insight there, therefore I'm closing this issue.