Am 14.02.19 um 17:45 schrieb Thomas Finneid: > On 14.02.2019 11:55, Markus Koschany wrote:> > >> What you can do of course is to patch sbt or scala. We use so-called >> quilt patches. For instance take a look at sbt. In debian/patches you >> can see several Debian specific patches that change the default Maven >> repository for example. > > Thats what I had in mind. > > Since you mentioned the sbt package, it contains builddeps directory > that contains jar files. the main sbt script in release uses maven > central as source of jars, but here it seems to be patched to use jars > from within the deb package.
It doesn't use jars from within the deb package. Frederic modified the scripts, so that they will search for jars in Debian's canonical directories. For Maven that is /usr/share/maven-repo and we have also /usr/share/java/ which is useful for Ant projects or if you want to specify a flatDir for Gradle projects. It is easier to understand if you take a look at existing Maven or Ant based packages in Debian. The reason for this layout is simple. We don't allow downloads from external repositories at build time because of security and DFSG reasons and we require that every piece of software (all dependencies) are packaged in Debian, so we can be sure the software meets our standards. If sbt depended on liba, libb, libc, those libraries had to be packaged first and their jar files would be installed into /usr/share/java/liba-1.0.jar /usr/share/java/liba.jar -> /usr/share/java/liba-1.0.jar and in case it's a Maven based project /usr/share/maven-repo/my/groupid/artifactid/1.0/liba-1.0.jar /usr/share/maven-repo/my/groupid/artifactid/debian/liba-debian.jar etc. You can see we provide a versioned and an unversioned jar file (just a symlink). The reason is we want to simplify upgrades and instead of patching a dozen pom files, we just declare a "debian" version. The benefit is we only have to fix one package in case of security issues but the disadvantage is that everything has to work with one version which can be a challenge depending on the library in question. > Thorsten glaser, mentioned something about using experimental to > bootstrap. Might that be what has happend here? used sbt to build an sbt > jar that can be used inside the deb package? Experimental is merely a playground for developers who think their packages are not ready for unstable yet. What you usually do is to bootstrap the package and build all those parts that are essential to get a functional compiler/build tool. Then you upload the package and the second upload will then remove the boostrapping code and depend on your uploaded package. Now you can build the package with itself because we have a working package in Debian. Markus
signature.asc
Description: OpenPGP digital signature
