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
