Hi Kai-Chung Yan, I don't have an answer to your question but I would like to point out that gradle [1] does not depend on SBT [2]. They do similar things but SBT is Scala oriented while Gradle aims to be a more generic build tool. Regarding your question, from my experience during Debconf Heidleberg I think Debian will accept any package as long as it is high quality and maintained. The issues around Jenkins are that it's a big piece of software with very active development and a big ecosystem of plugins around it. That makes it a very difficult thing to maintain from a security point of view. Stability and security means you need to keep changes to a minimum. If someone has a better explanation, please feel free to correct me. [1] http://gradle.org/ [2] http://www.scala-sbt.org/ On 24.01.2016 17:54, 殷啟聰 wrote: > Hi, > > 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? > > 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? > > So what if there are some new packages that depends on libraries of > Jenkins and someone wants to package it, what should he do? > > By the way, I am not using Jenkins in daily life, I am simply curious. :) > > Regards, > Kai-Chung Yan > > 2016-01-21 0:41 GMT+08:00 Emmanuel Bourg <ebourg@apache.org>: >> Le 14/01/2016 10:15, Thorsten Glaser a écrit : >> >>> Hrm, so is upstream’s packaging any good then? I have seen >>> so many attempts of upstream to package “for” Debian that >>> I don’t believe them unseen any more… >> >> Reproducibility put aside the upstream package is quite good. The >> dependencies and the paths used are correct. It even managed to upgrade >> my years old installation of Hudson and turn it into a shiny and up to >> date instance of Jenkins without losing anything. >> >> >>> … (plus I’d not know which version to pick, and “nobody >>> ever got fired for buying IB^W^Wusing what’s in Debian” ☺) >> >> That's probably true for the upstream jenkins package too ;) >> >> Emmanuel Bourg >> > > >
Attachment:
signature.asc
Description: OpenPGP digital signature