Open binarytemple opened 9 years ago
Just a suggestion - you may also want to consider using Bintray (https://bintray.com, used today by Homebrew itself, Vagrant, the Apache SW Foundation, and many more). You'd be able to use your own domain name + have a single source for apt, yum and regular file repos (disclaimer, I'm with Bintray).
@binarytemple FYI - package cloud just dropped its enterprise edition: https://enterprise.packagecloud.io/
What do you think of that service?
@mjbrender - sounds like just what we need.
I've mailed them for more info, and to confirm the above.
@binarytemple fantastic. Let's keep mapping this out a bit and bring it up internally once they response.
Response from packagecloud.io:
- Artifact signing is a bit of a tricky question. There’s two parts, the signing of the actual packages themselves and the signing of the repository metadata:
For package signing: yes, any signatures you add to packages will remain in the package for your end users to verify. Keep in mind that Debian package signatures are not verified by default.
For repository metadata signing: packagecloud signs all repositories with our GPG key since we are generating the repository metadata.
Check out our blog posts that go into the details on package and metadata signing: http://blog.packagecloud.io/eng/2014/11/24/howto-gpg-sign-verify-rpm-packages-yum-repositories/, http://blog.packagecloud.io/eng/2014/10/28/howto-gpg-sign-verify-deb-packages-apt-repositories/
- Yes, read tokens are used for issuing access to private repositories. Note: you cannot have public and private packages in the same repository, they need to be in separate repositories.
speaking of "packaging" We have noticed even on FreeBSD where you provide a legacy pkg_add capable package, however not a FreeBSD 9.X version capable of pkg install. We also noted that you utilized a customized package building system, and no FreeBSD "ports" per se. We have also noted that pkg_add any riak package does not register that specific package with the package database on FreeBSD systems. Just my thoughts and input on the way basho does packaging....
@mjbrender I think that providing traditional packages and vagrant boxes are broadly related but somewhat different concerns, because the build/publication paths for both will be probably use fairly different tooling and have different requirements around them.
@outbackdingo thanks for the info. I think we're going to be fixing up the Linux stuff first though. @mjbrender I don't see the connection with the Vagrant image stuff, apart from the fact that it's too hard (due to our distribution of stuff) to generate Vagrant images (although I've built plenty in the past). @danieldreier Agreed... The Vagrant stuff is kinda going off on a tangent.
Then again, if we hold off this issue a couple of months.. Riak 1.4 will probably get EOL'd and the whole issue will become rather a moot point.
I struck that idea from the record -- you all have good points. @binarytemple, is this all resolved when 1.4 is EOL? How do we ensure people can install the latest through homebrew / apt / yum?
In addition, in order to make any of these non-bundled repositories available to the Linux installation, the user must also install a GPG key using
apt-key
. That's two keys, one for apt.basho.com and one for packagecloud.io.All of these things, although hardly insurmountable: represent pain, and pain detracts from the users enjoyment of setting up their first Riak cluster.
I suggest that for every release (including 1.4.x series maintenance releases) a copy always be sent to packagecloud.io, and Riak 1.4.10/12 also be back-loaded so as to to support legacy users.
That way, for fresh installs, users can completely switch over to using packagecloud.