Sandro, I have multiple reasons for not contacting Wikimedia or using their work. The possibility of them having additions for their own purposes is very high. I believe starting fresh was easier than analyzing and debugging their repo.
Init scripts are recommended but not mandatory. Also, using a specific init system is acceptable is the maintainer decides so. Please see this link: https://www.debian.org/vote/2014/vote_003 I am clear on how packaging works. However, there are tons of policies scattered about, and mistakes will be made because of this. This is my first package; I think I've done fairly well given the situation. Cheers! Brandon On Wed, Jun 17, 2015 at 10:48 PM, Sandro Tosi <mo...@debian.org> wrote: > On Wed, Jun 17, 2015 at 10:16 PM, Brandon Bradley > <bradleytas...@gmail.com> wrote: > > 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. > > I just added the list to this reply. > > > > >> > >> * 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. > > still not an excuse not to contact them and/or base the packaging in > what they have alraedy done. > > > 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. > > bash scripts are the foundations of system administrations and are no > more no less difficult to debug than any other language. > > > > >> > >> * 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. > > you should provide a package which is ready to be uploaded without any > further modification > > >> > >> * 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. > > and i did reply, and init script is required (from my POV) > > >> > >> * 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? > > yes and all the other actions performed in the 'configure' branch > > > > >> > >> * 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. > > then the right way is to instruce systemd and the init script to read > from /etc/default/kakfa which is a file containing a boolean variable > (defaulting to False) to specify whether to start or not kakfa > > > > >> > >> * 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! > > I'm afraid you dont have very clear how packaging works: you need to > provide users with a binary package with contains all the files in > their final locations ready to be used. I suggest to follow this up > with debian-mentors for further clarification. > > Regards, > -- > Sandro Tosi (aka morph, morpheus, matrixhasu) > My website: http://matrixhasu.altervista.org/ > Me at Debian: http://wiki.debian.org/SandroTosi >
