Happy new year to all !
Some answers:
Ben says: “You haven’t done this yet!!! I’m concerned that if you don’t update as instructed in the old forum you may break your system”
No, I didn’t do it. Why? Because my system works. So I don’t see the need of fix it so urgently, as the “problem” is not serious and I’m able to use and work with my PC.
Why I want to update it now. Because I think that having the 2014.2, being the “very last” stable version, it’s better at the time of detect and fox errors and problems. As already was said on the old thread, I know that there’s some risk trying to change things in the way that Ben says, and I barely understand that (the Ben’s proposal) it’s probably the better way to change that.
HOWEVER, note that my question was only: why it says “2014.0” instead of “2014.2”. I’m not asking about the change from 2014.0 to 2014.1. I’m taking about change to 2014.2. Then, the point of my question was “catched” by @rugyada. Is it just a matter of a directory name? And the original question remains: WHY I should use 2014.0 when I want to update to 2014.2???
Now the new data: I follow the step that the Release Notes says: erase all previous repositories (using urpmi.removemedia) and added the (supposedly) new ones (using urpmi.addmedia --distrib…), using the command WITH “2014.0”. As @Ben said, the directory is “2014.0”. There’s no “2014.2” option.
I just reboot my PC. Guess what? Nothing to update !!!
$ su -
Contraseña:
# LC_ALL=C urpmi --auto-update --download-all --noclean
medium "main" is up-to-date
medium "main updates" is up-to-date
medium "Main32" is up-to-date
medium "Main32 Updates" is up-to-date
medium "contrib" is up-to-date
medium "contrib updates" is up-to-date
medium "contrib32" is up-to-date
medium "contrib32 updates" is up-to-date
medium "non-free" is up-to-date
medium "non-free updates" is up-to-date
medium "Non-free32" is up-to-date
medium "Non-free32 Updates" is up-to-date
medium "restricted" is up-to-date
medium "restricted updates" is up-to-date
Packages are up to date
# uname -a
Linux mypc.omv 4.1.12-nrjQL-desktop-1omv #1 SMP PREEMPT Sun Nov 15 14:42:41 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
# cat /etc/release
OpenMandriva Lx release 2014.1 (Phosphorus) for x86_64
I REALLY THINK that something of the folloging is (or are) wrong:
Or the command propossed in the “Release Notes” to update to 2014.2
Or the “/etc/release” file
Or the way files are named in the repositories
Or the way that OMV subversions (the “.0” or the “.2”) are established
The “final mix” is that, at least apparently, my system as a lot of 2014.0 files, the “release” file says I have the 2014.1, and if I trying to update to 2014.2 nothing happens, so I have the most updated (2014.2?) version, even after apply what “Release Notes” says to update to 2014.2.
As a clue, I have the “The Scion” wallpapers loaded (I didn’t loaded manually, they appear after some update several months ago), so I think that I have the 2014.2 in some way.
Do you think that it really worthwhile trying to change “distro-release-common” (from 2014.1-0.16 to 2014.0-0.24)? (I must apply the “risky” proposal by @Ben). To my limited knownledge, it’s much more easy to create a 2014.1-0-24 RPM file in the repository.
And now another question: Why /etc/release doesn’t says “2014.2” if I did what “Release Notes” says to update to 2014.2? Is it because of distro-release-*?
I insist: why distro-release-common-2014.1-0.24-omv2014.0.x86_64.rpm is not created after all? (note the 2014.1 after “common-”, but not after “0.24-omv”).
How the OMV subversion number (or why) is used?