https://bugzilla.redhat.com/show_bug.cgi?id=1594313
--- Comment #32 from jiri vanek jvanek@redhat.com ---
It seems too risky to keep this without by-in from Shenandoah folks. This has the potential to break x86_64 and aarch64 in strange ways.
Are they really out? I'm really afraid of leaving (again) behind. Can we keep it in untill the review is finished, so all is done with it in mind? If the shenandoah repo is still not accptable at that time, Then I will bow and remove it. Hmm?
So the steps I wont t do:
- rename generate_tarballs.sh to regenerate_systemtap.sh
- tune the script to point to current valid locations
- get rid of the icon and desktop file as ithave nothing common now
- we need to agree on systemtap versioning and releaseing (see stalled
thread on java-team)
- rename generate_source_tarball.sh to generate_openjdk_tarball.sh
- keep it as it is
- modidy update_package.sh
++ stop touching specfile ++ stop touching sources
- maybe rename it to generate-sources.sh
- simplyfy its logic.
++ prit a bit of what is ahppening
HUGE +1
Thanx for adding courage :)
- generate also systemtap (if necessary)
and so on
- its reason really si to replace comment you suggest, by pushed,
right-away for use script.
OK. Those are reasonable steps. Just to be clear on the expectations, which I'll make a requirement for this review to pass:
- For each source tarball there need to be clear instructions as to how to generate it. That includes all needed parameters to get the exact same tarball (reproducible tarballs) in a comment. I'll be testing it for each tarball individually.
- There need to be switches to the script to just generate one tarball or alternatively document steps as mentioned above, VERSION="jdk-11+19"PROJECT_NAME=jdk REPO_NAME=jdk bash generate_source...,
zzzz. I can survive comment saying what envrionmet variable to set to what :(
Changes to update_package I would like to keep for next update of sources
Like I said, if you are fond of update_package.sh, then this needs to get fixed immediately (or it'll never get fixed).
ok.
It should not be my workflow (although it grown into it), it should be genereic helper. If it do not serve that, then it should be removed. Still I like it *much more* then comment with "VERSION=..."
FWIW, with mono-repository these would also be possible instructions for the main tarball:
$ wget http://hg.openjdk.java.net/jdk/jdk/archive/jdk-11+19.tar.bz2 $ tar -xf jdk-jdk-11+19.tar.bz2 $ cd jdk-jdk-11+19 $ rm -rf src/jdk.crypto.ec/share/native/libsunec/impl $ patch -Np1 < %{SOURCEX} $ cd .. $ tar -cJf jdk-jdk-11+19.tar.xz jdk-jdk-11+19
The monolitic repo have huge performance problems when cloned. If this will be faster I will swithc to it. Thanx for reminding this approach.
btw - you highligh the reproducible sources - you mean after unpack, right? Or do you wont to tkae similar approach as https://src.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/tree/repackRe... did? Is it even possible with tar.xz?
Thanx for review!