All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tudor Holton <tudor@tudorholton.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] package/openjdk: modify site from mirror to official repos
Date: Mon, 02 Dec 2019 17:09:33 +1100	[thread overview]
Message-ID: <3c9e68edd0b8700b3914ff63ff773ed0@tudorholton.com> (raw)
In-Reply-To: <fa31990d-0f91-0eec-4b63-9d0f235daab2@mind.be>

On 2019-12-02 01:18, Arnout Vandecappelle wrote:
> On 27/11/2019 06:39, Tudor Holton wrote:
>> From: Tudor Holton <buildroot@tudorholton.com>
>> 
>> Since Java 11 (and possibly earlier), OpenJDK now has its own official 
>> repository
>> at hg.openjdk.java.net which is referenced in all OpenJDK 
>> documentation.
>> This patch brings buildroot into line with that source and allows 
>> consistent
>> patching both across projects and for patches specific to buildroot 
>> environments.
> 
>  I guess by switching to a different source repository, we're also 
> loosing some
> modifications that were done by AdoptOpenJDK, right? So could you 
> enumerate
> these changes (and possibly explain why they're not relevant/wanted
> for Buildroot)?

Thanks for looking at this. :-)

Well, it depends on who you believe and how good your crystal ball is.  
The current AdoptOpenJDK repos says "Mirror of 
http://hg.openjdk.java.net/jdk-updates/jdk12u/", but the hashes don't 
match.  Although, that could be something to do with the filename being 
ever-so-slightly different which obviously depends on how the hash is 
calculated.

Either way, changing to the upstream source removes the potential for a 
code injection between the upstream source and buildroot which, in our 
case, is essential to some buildroot-specific integrations in the 
pipeline (namely new Java 9+ module management, removal of Xorg 
dependency, and uClibC integration) which would be painful to apply 
upstream, and could have the potential to break buildroot patches in the 
middle, leading to patch wars (speaking from experience).
> 
> 
>> 
>> Signed-off-by: Tudor Holton <buildroot@tudorholton.com>
>> ---
>>  DEVELOPERS                   | 3 +++
>>  package/openjdk/openjdk.hash | 2 +-
>>  package/openjdk/openjdk.mk   | 8 ++++----
>>  3 files changed, 8 insertions(+), 5 deletions(-)
>> 
>> diff --git a/DEVELOPERS b/DEVELOPERS
>> index 991be89849..7c9cebfb2f 100644
>> --- a/DEVELOPERS
>> +++ b/DEVELOPERS
>> @@ -2365,6 +2365,9 @@ F:	package/redis/
>>  N:	Trent Piepho <tpiepho@impinj.com>
>>  F:	package/libp11/
>> 
>> +N:	Tudor Holton <buildroot@tudorholton.com>
>> +F:	package/openjdk/
>> +
>>  N:	Tzu-Jung Lee <roylee17@gmail.com>
>>  F:	package/dropwatch/
>>  F:	package/tstools/
>> diff --git a/package/openjdk/openjdk.hash 
>> b/package/openjdk/openjdk.hash
>> index 00d080aa3f..beed7a34a2 100644
>> --- a/package/openjdk/openjdk.hash
>> +++ b/package/openjdk/openjdk.hash
>> @@ -1,3 +1,3 @@
>>  # Locally computed
>> -sha256 
>> 5f73d86ed516173965b27754f1bb21374ccb1194a17c2d89d8018280ce5ffa78  
>> openjdk-12.0.2+10.tar.gz
>> +sha256 
>> b2bcad35656b00928683416f3480ad00363b00993eb711c3e1886e4fe77eefeb  
>> jdk-12.0.2+10.tar.gz
>>  sha256 
>> 4b9abebc4338048a7c2dc184e9f800deb349366bdf28eb23c2677a77b4c87726  
>> LICENSE
>> diff --git a/package/openjdk/openjdk.mk b/package/openjdk/openjdk.mk
>> index ea2555edcc..3081c2f895 100644
>> --- a/package/openjdk/openjdk.mk
>> +++ b/package/openjdk/openjdk.mk
>> @@ -7,7 +7,10 @@
>>  OPENJDK_VERSION_MAJOR = 12.0.2
>>  OPENJDK_VERSION_MINOR = 10
>>  OPENJDK_VERSION = $(OPENJDK_VERSION_MAJOR)+$(OPENJDK_VERSION_MINOR)
>> -OPENJDK_SITE = $(call 
>> github,AdoptOpenJDK,openjdk-jdk12u,jdk-$(OPENJDK_VERSION))
>> +OPENJDK_PROJECT = jdk-updates
>> +OPENJDK_RELEASE = jdk12u
> 
>  Is it relevant to create variables for these? Just use them directly 
> in the
> _SITE, like we do for most other packages.
> 
> 

This was inspired by a few other buildroot openjdk packages that have 
been floating around the internet.

It's more a style choice, but also an understanding of the upstream 
repos layout:

Since OpenJDK has multiple streams this may become needed later on.  
Things like aarch32 aren't in jdk-updates (yet).  Config.in may 
eventually be able to select the project and release, but I was trying 
to keep this all as close to the current version as possible.  Don't 
forget, also, that OpenJDK now has LTS releases, which I think would be 
preferable, but there will always be a demand for newer releases also.

I can concur to a simpler form if you prefer.

>> +OPENJDK_SOURCE = jdk-$(OPENJDK_VERSION).tar.gz
>> +OPENJDK_SITE = 
>> https://hg.openjdk.java.net/$(OPENJDK_PROJECT)/$(OPENJDK_RELEASE)/archive
> 
>  I suspect this is an autogenerated archive, right? Do you know how 
> reliable it
> is w.r.t. changes in the hash? Long ago, we've had problems with github 
> a couple
> of times, where suddenly the generated tarball would be slightly 
> different and
> the existing hash would break.
> 
>  I realize that it's hard to know for sure if the tarball is 
> consistent. But at
> least please check if there's nothing stupid like a download date
> embedded in it.

I can say for sure that we have now been using these archives for just 
over a year internally, since OpenJDK 11, and we haven't seen an archive 
hash change in that entire time.  This was a vast improvement on the 
previous Mercurial forest.  /archive is exactly as is sounds.  It's an 
archive that doesn't change, which is why it effectively negates the 
need for a "downstream" mirror.

Regards,
Tudor Holton

  reply	other threads:[~2019-12-02  6:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-27  5:39 [Buildroot] [PATCH 1/1] package/openjdk: modify site from mirror to official repos Tudor Holton
2019-12-01 14:18 ` Arnout Vandecappelle
2019-12-02  6:09   ` Tudor Holton [this message]
2019-12-02  8:40     ` Arnout Vandecappelle
2019-12-02 13:57     ` Matthew Weber
  -- strict thread matches above, loose matches on Subject: below --
2019-11-27  5:31 Tudor Holton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3c9e68edd0b8700b3914ff63ff773ed0@tudorholton.com \
    --to=tudor@tudorholton.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.