These may be alternatives for version numbering (I've tested them with dpkg --compare-versions):
As a complete upstream version: 42.85.20 Combining old and new schema: 042+stab085.20 El 26/03/14 17:07, Roman Haefeli ha escrit: > On Mon, 2014-03-24 at 09:40 -0700, Kir Kolyshkin wrote: >> Thank you for detailed position. I have already rolled back to the old >> versioning scheme, >> please check packages in wheezy-test and let me know if anything is >> wrong there. > > Things look pretty good in wheezy-test. Thanks for the work. > > Two minor issues: > > * There is still no changelog of the kernel in the package (or > I cannot find it, usually it goes to something like: > > /usr/share/doc/linux-image-2.6.32-openvz-042stab085.20-amd64/changelog.Debian.gz > > * The version of the meta package linux-image-openvz-amd64 is higher > (042+1) in wheezy than in wheezy-test (042stab085.20). When switching > from wheezy to wheezy-test, one has to remove and re-install the > package linux-image-openvz-amd64 in order to automatically install the > newest kernel packagelinux-image-2.6.32-openvz-042stab085.20-amd64 > > I'm not sure how to resolve the latter problem or whether it should be > addressed at all (switching from wheezy to wheezy-test can considered to > be one time thing). However, once the the current wheezy-test > linux-image-openvz-amd64 goes to wheezy, there is a problem because you > cannot downgrade packages. Either the version needs to be bumped with an > epoch version [1] like 1:042stab085.20 (ugly) or the versioning scheme > needs to be adapted (perhaps also ugly), but how? I can't think of a > truly satisfying solution right now. > > [1] https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version > > > Roman > > >> On 03/24/2014 09:04 AM, Roman Haefeli wrote: >>> Hi all, Ola >>> >>> I followed the recent discussion about OpenVZ kernel package management >>> for Debian. While I don't really have a qualified opinion on the subject >>> matter (personally, I slightly tend towards a new package for each >>> release), let me mention problems with the current situation: >>> >>> * 'uname -r' does not print the actual version (This already has >>> been mentioned in the other thread) >>> >>> * If there is a problem with a kernel update, I cannot easily revert >>> to the previous version. At our institution, we experienced cases >>> where a switch to the previous kernel because of a bug was necessary. >>> >>> * I'm trying to upgrade a machine right now from version 042stab084.26 >>> to newest 042stab085.17. I do: >>> >>> $ apt-get update && apt-get dist-upgrade >>> >>> and I'm prompted with the following dialog: >>> >>> $ Configuring linux-image-2.6.32-openvz-amd64 >>> $ ------------------------------------------- >>> $ >>> $ You are attempting to install a kernel image (version >>> 2.6.32-openvz-amd64) However, the directory >>> /lib/modules/2.6.32-openvz-amd64/kernel still exists. If this directory >>> belongs to a previous linux-image-2.6.32-openvz-amd64 >>> $ package, and if you have deselected some modules, or installed >>> standalone modules packages, this could be bad. >>> $ >>> $ If /lib/modules/2.6.32-openvz-amd64/kernel belongs to an old install >>> of linux-image-2.6.32-openvz-amd64, then this is your last chance to abort >>> the installation of this kernel image (nothing has been changed yet). >>> $ >>> $ If you know what you are doing, and if you feel that this image >>> should be installed despite this anomaly, Please answer n to the question. >>> $ >>> $ Otherwise, I suggest you move /lib/modules/2.6.32-openvz-amd64/kernel >>> out of the way, perhaps to /lib/modules/2.6.32-openvz-amd64.kernel.old or >>> something, and then try re-installing this image. >>> $ >>> $ Stop install since the kernel-image is already installed? >>> >>> If Debian does in-place kernel upgrades (a.k.a keeping the package >>> name while upgrading the kernel), they managed to never bother the >>> user with a question like this. I certainly know too little about >>> kernel package management to be of any help, but to me that dialog >>> indicates that something is still odd. >>> >>> >>> Those issues might be solved while sticking to the in-place upgrade >>> scheme and are not necessarily an argument against it. I just wanted to >>> mention them. >>> >>> Ranting aside, I am more than happy to see someone puts the effort into >>> making all the great OpenVZ software easily accessible for Debian >>> systems. For Debian, the situation has never been better before. Thanks >>> a lot for that work. >>> >>> Roman >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users@openvz.org >>> https://lists.openvz.org/mailman/listinfo/users >> > > > _______________________________________________ > Users mailing list > Users@openvz.org > https://lists.openvz.org/mailman/listinfo/users > _______________________________________________ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users