Hello Sandro! And thanks for your reply. Your questions are annotated below.
On Wed, Jun 17, 2015 at 2:56 PM, Sandro Tosi <mo...@debian.org> wrote: > Hi everyone, > I'm looking at Brandon's package for kafka, and here are some comments: > > * did you sent an email to debian-mentors asking for comments? it's > usually a good way to get exposure of a package and receive feedbacks > about it > I have not. I should and will very soon. > * there is already a packaging effort from wikimedia at > https://git.wikimedia.org/summary/operations%2fdebs%2fkafka.git/HEAD - > did you look at it (eventually contacting them to have the packages in > debian)? > Indeed, I found this. The work there is most likely acceptable. However, I believe that if they wanted to contribute this to Debian packaging that they would have already done so. Also, I find bash scripts hard to debug in some situations. As such, I will not be contributing init scripts myself. I would be more than willing to accept contributions that support init scripts. debian/kafka.service works great on Jessie and will be what I maintain. > * you mention gradle in Debian is broken: have you investigated what > needs to be done to fix it? > I have. I cannot find the specific issue again, but Debian's gradle package uses a very old version that breaks the Kafka build. I'll try to document the issue if I find it again. > * debian/changelog > - it still contains 'UNRELEASED', that should be 'unstable' instead > Ok! I thought it would be changed when the package is accepted. > * debian/control > - consider adding a Vcs-Browser field in source stanza > - short description should start with a lowercase letter > > * debian/kafka.links > - is empty and could be removed > Ok! > * debian/kafka.lintian-overrides > - I think there is still a lot of "heat" around it and I would > strongly advice to provide an init script > Answered above. > * debian/kafka.postinst > - you do some operations in 'configure' but it seems you dont undo > them when removing/purging the package, which should happen instead > Are you talking about adduser and addgroup? > * debian/rules > - consider using the more compact: --with A,B instead of --with A --with > B > - it looks really suspicious the usage of HOME: have you tried to > build your package in a clean chroot? > - override_dh_systemd_start: true is, to say the least, unexpected, > what it is for? > - Ok! - `./gradlew clean` was not using the chroot root user's home. This usage does that. It is strange, and I hope to find a better way to do it. - It is there so `dh_systemd_start` does nothing. I don't want Kafka to start after installation in case someone is running ZooKeeper on another node that is not up yet. > * debian/watch > - please provide it > Ok! > the package fails to build from source (FTBFS as you might find > usually written) in pbuilder exactly when using HOME: > > dh_auto_clean > GRADLE_USER_HOME=/tmp/buildd/.gradle ./gradlew clean > Error: Could not find or load main class > org.gradle.wrapper.GradleWrapperMain > debian/rules:15: recipe for target 'override_dh_auto_clean' failed > make[1]: *** [override_dh_auto_clean] Error 1 > > I need to make this clear in some documentation. The user should have a Gradle installed from binary distribution and run `gradle build` to bootstrap the Gradle wrapper. Then, the user should use `./gradlew build` to build Kafka. Kafka does this to remove binary artifacts from their source distribution (https://issues.apache.org/jira/browse/KAFKA-1490) and not a requirement of mine. Also, I use git-buildpackage to build the package. Like so: `gbp buildpackage`. Another documentation note! Cheers! Brandon
