[rb-general] [jvm] How to share rebuilder attestations

[Hervé Boutemy]

Le mercredi 9 janvier 2019, 14:51:33 CET Eli Schwartz a écrit :
> On 1/9/19 2:52 AM, Hervé Boutemy wrote:
> > I see the advantages of this scenario
> > but I also see 1 key drawback = the buildinfo has to be reproducible, and
> > in the case of JVM artifacts in public repositories like Maven Central,
> > this could be really problematic since every publisher has his own build
> > platform, with his own JDK patch level and own OS (usually one of
> > Windows/Linux/Mac, to just limit the diversity but I'm sure it's even
> > more diverse)
> > I fear that you can do that because of the strict environment control that
> > a Linux distro,  but this cannot be the same  with the public JVM repos
> > 
> > can you provide me a pointer to an ArchLinux JVM artifact (preferably
> > built
> > with Maven...) that I could try to reproduce myself, please?
> 
> https://www.archlinux.org/packages/community/any/maven/
> 
> This is our maven package -- anything built using maven will be listed
> under Required By, which is only 5 packages.
> 
> https://www.archlinux.org/packages/community/any/gradle/
> 
> Gradle has another 3.
> 
> https://www.archlinux.org/packages/extra/any/ant/
> 
> Ant has a few more -- about 31.
thank you, very instructive: if someone can provide equivalent links for 
Debian please, this would be great

there is one thing I didn't find though: where are buildinfo files?

one very interesting part is your PKGBUILD files, that contain the recipe for 
building the software then the package, and is a shell script file, with 
properties to define prerequisites
IMHO this is one thing where our current work on buildinfo files for the JVM 
will require some work: the recipe for building is in the buildinfo and 
implicit.
There is also the difference between "depends" and "makedepends", with depends 
containing a range like "java-environment>=7", but makedepends defining a 
concrete major version "java-environment=8".

> 
> > yes, using external server to download dependencies is a default
> > behaviour,
> > but if someone wants to override to get his own artifact repository
> > instead, you can do it with parameters (at least with Maven, but I
> > suppose every build tool can)
> 
> Is this something that could be packaged and then referenced as a
> directory path?
yes, using settings.xml mirror
https://maven.apache.org/ref/3.6.0/maven-settings/settings.html

By doing so you'll discover the bunch of binaries you're downloading, both as 
plugins during the build but also tool dependencies that are then bundled in 
your package (for example in Maven every file lib/ that is not named maven-
*.jar): you'll discover real dependencies that would ideally have to be built 
from sources

> 
> > let's dig into the JVM requirement:
> > from experience, bytecode produced by major JVM versions is really
> > different (tested with JDK 7, 8, 9, 10 and 11)
> > but patch level is not
> > since what we record easily is the full JDK version (major version + patch
> > level), we mix strong requirement (major version) with something that is
> > not that important (patch level) and that we would like to accept
> > variation (I already have 5 JDK versions on my computer for 5 major
> > versions, if I need to have strict patch level, I'll finish with
> > hundreds, since once again I want to rebuild every artifact from Maven
> > Central, that has been built by anybody in his own personal environment.
> 
> I see the problem, although I wonder, if patchlevel bytecode is stable
> then could this be solved by defining a buildinfo that only records the
> major version?
as see before with makedepends containing "java-environment=8", you don't 
record the patch level as a requirement.
I didn't see your buildinfo, but having major level in PKGBUILD as requirement 
and detailed effective version in buildinfo makes sense: since you have 2 
separate files, you don't have any issue, you could precise the requirement if 
necessary

Regards,

Hervé

> 
> Might not be worth the downsides though.