Change of NethServer upgrade policy

mirrors
ipv6
yum

(Davide Principi) #1

Thanks to the big work of the upstream QA team, a minor version upgrade in CentOS is smooth and painless. A CentOS machine fetches the security updates from an URL like

http://mirror.centos.org/centos/$releasever/updates/$basearch/

Where $releasever is currently 6, and $basearch is x86_64.

This is different in NethServer, because our YUM repositories are always accessed with the minor version number. For instance, we use 6.7 instead of 6. This difference causes troubles with IPv6 and YUM, and has been signaled various times in other threads; for instance 1246, 2171, 2256.

I propose a change of the upgrade policy: let’s adopt the same policy of upstream and point to the major number (6) repository. When CentOS 6.8 is released NethServer behaves exactly like CentOS; thus it continues to receive security updates, that is very important for me.

What do you think?


CentOS 7.4 - Proposal for repository policy change (temporary)
[Proposal] New way to handle upstream updates
NethServer 6.8 beta1 Released!
#2

Me too.

Out of curiosity, immediately following this transition, would a current, up to date, NS be facing a huge update push, as in, opening the floodgates?


#3

It sound good for me. :smiley:


(Davide Principi) #4

Nothing changes in the immediate, as far as 6 points to 6.7.

Edit:

Moreover, when CentOS 6.8 will be released, any NethServer installation will immediately receive the same updates of a basic CentOS. We can still retain some time to develop and test new features before releasing the new NS 6.8 ISO.


CentOS 6.8 is out, updates are available
(Davide Principi) #5

(Davide Principi) #6

I want to get more feedback! Please, reply!


(Giacomo Sanchietti) #7

I totally agree with this approach!


(Stefano) #8

AFAIR, this is one of the first request I made, many months ago…

system updates must always be applied asap


(Filippo Carletti) #9

Me too! We could deal with potential problems when CentOS will release 6.8.


(Stefano) #10

since NS is strictly upstream complian, and knowing RH’s policies about continuity, reliability and availability of services, I think we have nothing to be worried about


(Stéphane de Labrusse) #11

We ought to follow mainstream updates hence i have no problems for that.


(Alessio Fattorini) #12

(Davide Principi) #13

The upgrade policy change requires a very little code change :slight_smile:


(Davide Principi) #14

The code is deployed. The upgrade policy has changed. What is going to happen now? nothing :blush: