That’s a good point.
What are you locking? The Update Policy? The version? I guess you need to say it
That’s a good point.
Oooohhh! Very interesting point and train of thought…
I like the Locked/Unlocked idea, however a bit of clarification may be needed. I may come back with some suggestions unless someone beats me to it first.
Software update policy: locked/unlocked. What is locked is the origin of the updates, so we can change the label to
Software update origin:
- Unlocked - Consider updates to version 7 from all available software repositories
- Locked - Limit updates to repositories specific to version 7.X.Y. Other repositories are considered only when new modules are installed
Please @bwdjames help me to improve those sentences (and English too)!
Unlocked - Consider updates from all available software repositories
Think the Locked one is okay, will ponder over it on the weekend.
Everything is ready, but changes are quite big so @davidep has written a huge an detailed list of test cases:
Now we need help from all of you to test and release it soon!
Yes please review also this pull request for the Software center admin’s guide
This morning @giacomo and I introduced a cron job that can switch the software origin automatically when a new CentOS distribution release is available /cc @dz00te. I updated the admin’s guide PR accordingly:
See also this change proposal to the Software center labels:
Great solution, I wish to try it. How can I get it?
It will be available soon for NethServer 7.5!
nice, i like the way you decide to manage the updates lock… and i see the test cases (thank you for writing them), but i am wondering if i can test the new procedure on 7.4
i installed the testing package nethserver-base-3.2.0-1.17.g7561792.ns7.noarch.rpm on 7.4 and now on Software center i have
and this is what is expected, then i’ve tried to execute the cron script, to see if NsReleaseLock switch do disabled… but it seems that the script gets $ns_release and $ce_release with the same version: 7.5.1804
i know it’s not a test case but the idea was to test the new feature on 7.4 to see what would have happened in a real case…
do i need to update some other package?
if you think it’s useless i’ll start trying on 7.5
Yes, I adapted the mirrorlist script to work with this new feature today: https://github.com/NethServer/mirrorlist/pull/9/files
However the only way to really test it on 7.4 is quite complex because it does not exist any more, as we’re in 7.5 now. To get an idea:
- git clone mirrorlist in a web server and fix the release numbers for testing
- configure the “mirrorlist.nethserver.org” virtualhost in the web server
- add a DNS override in nethserver testing VM to point to the fake server
(I already suggested a similar solution for a different problem here: YUM update repository problems (from Russia))
Thank you for your input! This weird idea was your
Do you remember?
Looks great. I hope this clarify any doubts
All related packages have been released.
RC is coming!
NethServer 7.5.1804 rc released
Collaborative draft of 7.5 release announcement
2 posts were split to a new topic: NethServer 7.5 rc released
tnx, done the fake server, now the cron script correctly enable NsRelease lock due to mismatch of version
CentOS and NethServer releases are different! CentOS: 7.5.1804 NethServer: 7.4.1708 NsReleaseLock is now enabled.
now do you think i could persuade Software Center that a new version 7.5rc is available for install?
doh! usually my answer to this question it’s almost always: no
I have to admit: my memory is worse than my English but at least I like my ideas
tnx for your work
2 posts were split to a new topic: Download updates after scheduled backup
I like your sense of humor… And I generally have the same issue myself…
Hi James, so I think your memory is working very well, because I think your English should be better as the English of most others here
A post was split to a new topic: SCLo repositories version lock