Re: About Jenkins in Debian
Le 24/01/2016 16:54, 殷啟聰 a écrit :
> So if my understanding is right, Jenkins is highly likely to be
> removed from Debian. And the reason behind this is because the release
> cycle of Jenkins is way too short and upstream already provides .deb?
Yes that's correct. The security fixes for Jenkins are too difficult to
backport because the code is constantly refactored. The last time a
security issue popped up it involved introducing new packages, and we
usually don't do that in stable.
As a comparison point, Tomcat development is quite fast too with monthly
releases sometime. But the code is more stable and the security fixes
are thoroughly documented [1] such that we know exactly what to backport.
> So this makes me think about what exactly should be packaged into
> Debian. There are not too many softwares providing .deb distributions
> in upstream, but what if some of the softwares whose packages are
> already in Debian starts to provide upstream .deb, will we still have
> the motivation to keep maintaining it? For example, Gradle does not
> have .deb in upstream, but SBT does, and Gradle indirectly depends on
> SBT, then should we package SBT into Debian as well, which even though
> means lots of work?
SBT is worth packaging even if upstream provides a .deb, because we
can't use the upstream package to package SBT based applications in
Debian. Build tools are also less sensitive to security issues than web
applications like Jenkins.
> So what if there are some new packages that depends on libraries of
> Jenkins and someone wants to package it, what should he do?
In this case we package the Jenkins libraries, but probably not the full
web application. Fortunately most of the reusable parts of Jenkins are
already available as separate libraries, so it's unlikely that we need
the full Jenkins libraries.
Emmanuel Bourg
[1] https://tomcat.apache.org/security-7.html
Reply to: