[CentOS-devel] SIGs, versions, and yum update

Wed Feb 10 17:04:19 UTC 2016
Troy Dawson <tdawson at redhat.com>

On Wed, Feb 10, 2016 at 11:00 AM, George Dunlap <dunlapg at umich.edu> wrote:
> On Wed, Feb 10, 2016 at 4:36 PM, George Dunlap <dunlapg at umich.edu> wrote:
>> A couple of weeks ago I was just about to push an update of Xen 4.4 to
>> Xen 4.6 to the Virt SIG repositories, and I suddenly got some
>> push-back from the users, because Xen 4.6 has some fairly significant
>> changes -- particularly the removal of the old toolstack daemon called
>> xend.  (xend had been disabled by default and had lots of messages
>> warning about the upcoming deprecation, even in 4.4.)
>>
>> It seems some users have the expectation that they should be able to
>> run "yum update -y" on their servers on a regular basis, without
>> having to worry about accidentally updating to a new major version
>> that break things.
>>
>> So one thing that was proposed was that we make separate packages
>> somehow, such that users would have to actively request the newer
>> version rather than getting it automatically.  (This could be done
>> either by having a package named xen46, or by having separate
>> centos-release-xen-46 package that pointed to an entirely different
>> repository.)
>>
>> But of course, other users pushed back on that idea, saying they would
>> always rather have the latest version Just Work, and didn't like the
>> idea of having to manually keep track of what version was installed on
>> any given system, or of actually finding out that there's a new
>> package and what that new package name is.
>>
>> KB and I chatted about it at the Virt SIG meeting, and decided that we
>> should touch base with the other SIGs to have a consistent message.
>>
>> As for my own opinion: I can see both sides of the story, and as a
>> package maintainer I'd be willing to do either one.
>>
>> But on the whole I tend to side with the "latest version" crowd.  I
>> think you should always be looking at what "yum update" gives you
>> before installing it; even minor updates I can't guarantee are going
>> to break things.  And I'd rather the installation instructions be
>> simple (don't have to mess around with version numbers), and I'd
>> rather people not have to fish around for major updates (or run
>> packages with unpatched security vulnerabilities because they didn't
>> realize their packages were now obsolete).
>>
>> What do other SIGs think?
>
> Splitting the difference from a user point of view, here's another option:
>
> * Have a separate repo for each major version
> * Have the centos-release-xen-NN packages which always point to a specific repo
> * Have the centos-release-xen package always point to the most recent repo
>
> This is a tiny bit more infrastructure work, but makes it easier to
> test both minor releases and major releases; it also makes it easier
> for volunteers to step up and maintain older versions if they want.
>

+1 to this idea