[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: old version of scala

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.jar -> /usr/share/java/liba-1.0.jar

and in case it's a Maven based project



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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: