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!
Collaborative draft of 7.5 release announcement
NethServer 7.5.1804 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