Is a native packages repository still maintained?


(Adam Gabryś) #1

Just a quick question: do you plan to update the native packages repository? The latest available version to download is SonarQube 7.1. The repositody is (has been) maintained by Godin (Evgeny Mandrikov).


(G Ann Campbell) #2

Hi Adam,

As I mentioned in the 7.2 announcement, there’s no 7.2 image on purpose. Why? Well, as you note, the repository has been maintained to date by Godin on an at-best basis. Then we had the packaging changes in 7.2 and the question became how to replace 1 package with 4.

Rather than making hasty decisions, we set the whole issue aside to give us time to look at incorporating this maintenance into our regular procedures.


(Adam Gabryś) #3

The answer is perfect :blush: I just wanted to know if the project was abandoned :slight_smile:

(Stephan Schuster) #4

Hi Ann,

do you have any information when current RPM packages will be available?

We would love to upgrade our SonarQube 7.1 (developer edition) instance to the current version, but using the ZIP-distribution is not an option for us.

Best regards

(G Ann Campbell) #5

Hi Stephan,

There will not be RPM packages for 7.2. Will there be RPM packages for 7.3 (imminent)? No. Not at initial release and not later. We’re not doing RPM packages, or Docker images, or… until we get a better handle on how we want to deal with non-zip distributions.


(Nicolas Bontoux) #6

Would be interesting to get more details into why that is not an option!

(Stephan Schuster) #7

Hi Nicolas,

using the package manager to install software on linux distributions is the standard way to go. It is less error prone than installing from a non-standard ZIP-distribution, needs less manual setup and is easier to update.

As the official installation guide explicitly mentions the native packages for Linux (, we chose this method to setup our server instance. Our internal update processes for our infrastructure rely on the package manager of the operating system (CentOS) and we do not want to change that.

Best regards

(G Ann Campbell) #8

Hi Stephan,

Thanks for pointing that out. I’ve edited the docs.


(Udo Rader) #9

After wondering, why our sonar installation would not update anymore, I finally found this thread.

Could you please elaborate a little bit more what the problem is with creating updated packages? If there are no fundamental issues, I’m sure “the community” (including myself) is willing to help out with those packages.

I checked the SonarQube sources on github, but I did not find the package specs for RPMs and debian, it would be very easy to start from something existing.

(G Ann Campbell) #10


This started as someone’s off-hours side project. He wants a life now. Transferring it to a team responsibility is not something we take lightly. We’re planning to resume releasing Docker images for the community edition “soon”, but no current plans on RPM.


(Udo Rader) #11

thanks for the clarification.

So just to be 100% sure I understand you correctly: there’s no way you can provide the source RPMs/debian package sources for the existing 7.1 package?

Because not needing to completely reinvent the wheel would tremendously help any potential efforts to revive the package building.

(G Ann Campbell) #12


To be crystal clear: we will not provide an RPMs/debian package for 7.1.


(Adam Gabryś) #13

If somebody wants to maintain RPM packages, then:


(Udo Rader) #14

yes, that’s where the stale packages are. But on sourceforge you only find the binary packages, but not the specs how to build them.

In order to easily revive building, the SRPMS (Source RPMS) should be provided, too, and the same goes for the debian build spec files, and they are not there.

But never mind, sorry for the noise, it just would have been a nice and easy starting point.

Instead, I will now have a look on how the guys at ArchLinux are building their package and will craft our own debian packages out of that.


(Xavier Bourguignon) #15

You can find the specs on the github repository:

(Thomas H Jones Ii) #16

Bugger. Our IA folks tend to prefer the auditability of RPMs. Yeah, it wasn’t an “official” RPM, but, that the documentation used to link to it was “enough”.

Should be worth noting that having something - particularly a tool that’s used for security-related activities - provide in a verifiable packaging is a big plus. Always nice when your security scanners can do something basic like rpm -V and see if things are different than how the packaging thinks they ought to be (and validate that the installed packaging is the same as your designated source of truth).