Comment 6 for bug 2044019

Hi Rico,

Thanks for the clarifications!

> 1) 2) 3) 6) are packaging bugs regarding Java support
> Those are needed to allow Java support to be disabled on specific archs if needed.
> Fortunately this wasn't required yet while the already applied mitigations to the bridgetests still are sufficient.

So, it does look like this is not _required_ right now, correct?
(i.e., no archs are getting Java support disabled in this SRU.)

I take this from your comment ("if needed" and "wasn't required yet")
_and_ `d/rules` assignments of OOO_BASE_ARCHS and OOO_REPORTBUILDER_ARCHS,
which remain the same value ("amd64 arm64 armhf ppc64el riscv64 s390x").

In this case, I guess such changes should not be included in this SRU,
but left for when it is actually needed; maybe others can comment too.

And perhaps a separate bug report with more details would be recommended,
but please do not work on this at the moment, while others don't comment.

> 4) 5) follow the upstream CMIS changes
> Upstream bumped the internal requirement of libcmis which finally allows the proper CMIS service support.
> Unfortunately it had to be disabled before because it was broken.

Understood.

I reviewed some of the docs/changes related to this, and this scenario
is more complex, since this (CMIS support) is a feature, with different
considerations for SRU (e.g., support in LTS and newer interim releases).

I'll have to ask for others with more experience in such case to comment,
but these are some thoughts for now:

CMIS is a standard related to a feature for opening/saving files on remote servers [1].
"LibreOffice supports many document servers ... that implement the OASIS CMIS standard."

[1] https://help.libreoffice.org/7.6/en-US/text/shared/guide/cmis-remote-files.html

In general, features only land in the development release, until feature freeze [2],
but there are cases for stable releases as well, when considering LTS releases: [3]

[2] https://wiki.ubuntu.com/FeatureFreeze
[3] https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases

"""
For Long Term Support releases we sometimes want to introduce new features.
...
To avoid regressions on upgrade, any such feature must then also be added to any newer supported Ubuntu release.
...
For new upstream versions of packages which provide new features, but don't fix critical bugs, a backport should be requested instead.
"""

So, theoretically, enabling CMIS in Mantic could meet the requirement to have it
in Jammy, and it is (jammy-updates 1:7.3.7-0ubuntu0.22.04.3 has ENABLE_CMIS=y).

It just turns out to be disabled in Lunar (lunar-updates 4:7.5.8-0ubuntu0.23.04.1
has ENABLE_LIBCMIS=n, I guess it might be due to issues/broken as you mentioned?),
so there's some intermediary release with it disabled.

> (continuing)
> Upstream chose Openssl as official choice for this feature/combination which was followed here.
> But it would be possible to continue using gnutls if the SRU requires it.

Ack, thanks for clarifying.
In this case, if libcurl4-gnutls/openssl were only being used due to ENABLE_CMIS,
which is disabled in mantic-release, then maybe we could change it, as it would be
effectively the only usage of it.
But it turns out it's apparently already used due to ENABLE_WEBDAV, so changing it
would affect something already present in mantic-release, so at least initially,
keeping it as-is sounds better -- unless there's an upstream rationale that gives
good reasons for switching, sure (and assessing/dealing with the change in Mantic).

I'll ask for an additional review on these points.

Thanks again for all your work on this SRU and its review!