jansi 2.x and jline 3.x
by Jerry James
Hi all,
I would like to keep jacop in Fedora. It is in danger of removal, due
to the orphaning of scala. I've taken a look at keeping scala in
Fedora, and updating it to its most recent version; see:
https://copr.fedorainfracloud.org/coprs/jjames/scala/
One issue is that recent scala needs jline 3.x (we have 2.x in
Rawhide), and jline 3.x needs jansi 2.x (we have 1.x in Rawhide).
Neither is backwards compatible with its previous major version. I
have made jansi 1.x/2.x and jline 2.x/3.x parallel installable, but
there is still at least one issue. The current jansi package
Provides:
jansi = 1.18-5.fc33
mvn(org.fusesource.jansi:jansi) = 1.18
mvn(org.fusesource.jansi:jansi-project:pom:) = 1.18
mvn(org.fusesource.jansi:jansi:pom:) = 1.18
osgi(org.fusesource.jansi) = 1.18.0
The jansi2 package on COPR Provides:
jansi2 = 2.1.0-1.fc34
jansi2(x86-64) = 2.1.0-1.fc34
libjansi.so()(64bit)
mvn(org.fusesource.jansi:jansi) = 2.1.0
mvn(org.fusesource.jansi:jansi:pom:) = 2.1.0
osgi(org.fusesource.jansi) = 2.1.0
There is overlap between the Provides, albeit with different version
numbers. How should this be handled? I guess that packages that need
version 1.x would have to include "BuildRequires: jansi < 2" and
"Requires: jansi"?
Also, is it better to keep the existing jansi and jline packages, and
add jansi2 and jline3 packages as I have done on COPR, or would it be
better to add jansi1 and jline2 packages containing the current
contents of jansi and jline, and then move jansi and jline to their
latest versions?
I appreciate any thoughts anyone has on the matter. Regards,
--
Jerry James
http://www.jamezone.org/
2 years, 11 months
- 4
- 18
Macros controlling the source/target/release level flags for javac
by Jiri Vanek
Hi!
I had risen this topic during jdk11 bump. but it somehow get lost.
The idea is, to provide rpm macros, keeping the default source/target eventually - for jdk11 and up -the release - numbers for javac to use.
Then to provide tooling, which will help packagers to use them - for ant and maven it should be simple. For others, probably nothing to do on our side, each packager will be able to patch/sed theirs builds as necessary (Still it will help a lot for future).
I do not know how to provide them as default (except hardcoding in xmvn, and only allow to disable them on demand).
This will smooth the bump to jdk17 in f36 really a lot.
Thoughts?
J.
--
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek(a)redhat.com M: +420775390109
2 years, 11 months
- 5
- 19
- ← Newer
- 1
- Older →