New package: Orthanc-1.11.2

[gcarlos64]

Testing the changes

• I tested the changes in this PR: briefly

New package

• This new package conforms to the quality requirements: YES

Local build testing

• I built this PR locally for my native architecture, (x86_64-LIBC)

[abenson]

One commit per template

[ahesford]

General comments (this is not exhaustive):

• Are all of these shared libs really necessary for linking by other packages? If not, leave them out of common/shlibs.
• One commit per package, one package per commit. Split each of these into a separate commit in the same PR.
• Remove version restrictions in hostmakedepends and makedepends. Version enforcement makes no sense here because the repository specifies a single version of the package; whatever is current. It either builds with that version or it's broken.
• What is the purpose of the Orthanc-{DicomWeb,PostgreSQL,Python} packages? They aren't reference by any other templates.
  • If Orthanc-Python really doesn't work with py3.11, that's a problem, because we'll be moving to py3.11 soon and I'd like to minimize potential breakage caused by the addition of new specialty packages in the meantime.
  • If Orthanc-Python is a Python package, it should depend on python3.

[gcarlos64]

@ahesford

* Are all of these shared libs really necessary for linking by other packages? If not, leave them out of `common/shlibs`.

Done.

* One commit per package, one package per commit. Split each of these into a separate commit in the same PR.

Done.

* Remove version restrictions in `hostmakedepends` and `makedepends`. Version enforcement makes no sense here because the repository specifies a single version of the package; whatever is current. It either builds with that version or it's broken.

Done.

* What is the purpose of the `Orthanc-{DicomWeb,PostgreSQL,Python}` packages? They aren't reference by any other templates.

These are some plugins i decided to package, it isn't requiered by the main package (Orthanc), but as these makedepends of Orthanc I added them into this PR.

  * If `Orthanc-Python` really doesn't work with py3.11, that's a problem, because we'll be moving to py3.11 soon and I'd like to minimize potential breakage caused by the addition of new specialty packages in the meantime.

It works, you just need to pass a flag with the major python version. As I passed python 3.10, i decided to restrict it on the template, but I understand now that it doesn't make sense and I've removed it. Now I need to get the python version from the upstream repo and pass it to configure_args. I'll try some way to do it.

  * If `Orthanc-Python` is a Python package, it should depend on `python3`.

It isn't, it's mostly like a binding instead.

[Chocimier]

I need to get the python version from the upstream repo and pass it to configure_args

see https://github.com/void-linux/void-packages/blob/master/Manual.md#python-packages

[gcarlos64]

I need to get the python version from the upstream repo and pass it to configure_args

see https://github.com/void-linux/void-packages/blob/master/Manual.md#python-packages

thx, now I'm using the py3_ver var.

[Chocimier]

Please check that it still builds after a round of review.

[gcarlos64]

Should I specify python3 on depends of Orthanc-Python? It don't explicity depends, but if it's compiled with python 3.10, as example, you cannot use it with python 3.11, as you need to compile with the specific python version flag. I'm thinking in put something like depends="python3>=${py3_ver}<$(( ${py3_ver} + 1 ))" (probably it shell expansion don't work, it's just to illustrate my idea)

[ahesford]

No, just depend on python3. We only support one version of py3 in the repository and I bump every Python package when we do a minor version jump.

[gcarlos64]

No, just depend on python3. We only support one version of py3 in the repository and I bump every Python package when we do a minor version jump.

Of course, but I'm thinking on some case as version hold by user. In that example, the xbps shouldn't allow to upgrade python to 3.11 if the user holds Orthanc-Python on a version wich depends on 3.10.

[gcarlos64]

Now all the packages are building successfully on my local.

I'll try to cross build to the others archs now.

[Chocimier]

version hold by user

This is already covered by dynamic linking tracking, look for SONAME: libpython3.10.so.1.0 <-> python3>=3.10.0_1 in build log.

[gcarlos64]

version hold by user

This is already covered by dynamic linking tracking, look for SONAME: libpython3.10.so.1.0 <-> python3>=3.10.0_1 in build log.

Ahh okay, so don't I need to specify python3 on depends?

[gcarlos64]

I marked all packages (except civetweb) since dcmtk, a dependency of Orthanc, need running some code on target arch to generate a header for crossbuild. It can be done running a compiled test (a single .cc present on distfile) on each arch and providing its generated headers together to package and copying it to desired directory, what seems a little tricky to maintain.

[gcarlos64]

I just updated Orthanc and Orthanc-DicomWeb to upstream version and made a change o Orthanc template accordingly Orthanc documentation. Also I tested the build on native aarch64 and everything seems fine.

[github-actions]

Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.