Docs: edited Documentation/distributions.md#centos

[lsm5]

The CentOS community build for rkt is not ready due to pending systemd
upgrade issues. The docs should reflect this.

[ghost]

Can one of the admins verify this patch?

[lucab]

Sorry for being late to the party @lsm5, I see you are going a great length to get it properly packaged.

At this point it looks like most of the friction is due to upgrading systemd on the host, which will in turn be needed to assemble the stage1-host aci. Given the status of the legacy environment, what if instead of backporting all of this you just build the stage0 only?

I'm not suggesting this as the default packaging strategy for current/rolling environments, but for old environments it may help in keeping your packaging task feasible.

Practically, this translates into:

./configure --with-stage1-default-name=coreos.com/rkt/stage1-coreos --with-stage1-default-version=1.16.0
sudo ./build-*/target/bin/rkt trust --trust-keys-from-https=true --prefix coreos.com/rkt https://coreos.com/dist/pubkeys/app-signing-pubkey.gpg
sudo ./build-*/target/bin/rkt fetch coreos.com/rkt/stage1-coreos:1.16.0
sudo ./build-*/target/bin/rkt run quay.io/coreos/alpine-sh --exec echo -- hello world

[lsm5]

hey @lucab, I got some pointers from the systemd guys on fixing the systemd rpm. Let me get back to you on this.

The ./configure options you mention above would imply pulling in a CoreOS image at buildtime, is that correct? I don't think that'd be agreeable to CentOS. Fedora was certainly against pulling/bundling another distro at buildtime.

[lucab]

@lsm5 sorry for not being explicit, my example was showing both build- and run-time. To draw a better line, your build-time would be:

./configure --with-stage1-default-name=coreos.com/rkt/stage1-coreos --with-stage1-default-version=1.16.0
make -j

while users run-time would be:

sudo rkt trust --trust-keys-from-https=true --prefix coreos.com/rkt https://coreos.com/dist/pubkeys/app-signing-pubkey.gpg
sudo rkt fetch coreos.com/rkt/stage1-coreos:1.16.0
sudo rkt run quay.io/coreos/alpine-sh --exec echo -- hello world

I'm not saying that this should be the default packaging behavior, but given the modularity of our stage architecture I think this is something you may consider for already-frozen stable releases.

I'm not a RPM user myself, but I think the same comparison could be done for the DEB world: unstable/testing are able to catch up and provide a stage1-host, while stable-backport may fallback to an external stage1 in order to avoid a complex backport mess.

[s-urbaniak]

@lucab This being a documentation change, is it ok to merge as-is, and follow the build discussion in a separate issue?

[lucab]

@s-urbaniak Moved my comment to #1305 (comment)

LGTM