<div dir="ltr">Hi<div><br></div><div>I can give you some additional feedback on what I think is the motivation for why the Debian packages was done this way.</div><div><br></div><div>1) Debian kernels are tested a lot before each release. The release is done every second year or so and there is a freeze period of at least a half a year with a lot of testing involved.</div>
<div>2) The main motivation for this change is probably that the kernel maintainers do not want to wait for FTP maintainers for every new version uploaded. If you create a new package in Debian you have to wait for FTP maintainers approval before it can reach the archives.</div>
<div>3) There is probably one more motivation and that is the Debian archive size. It has grown over the years and the kernel is a quite significant size of it. If every new kernel is kept for a while that cause a large archive. Keeping the package name solves this issue.</div>
<div>4) There is one more thing as well. That is that there are quite a few module packages in debian and they have to be re-built when the package name is changed. If the name can be kept (see ABI too below) they do not have to be and that release some load on the build infrastructure.</div>
<div>5) Still kernel maintainers are aware of ABI compatibility. This is the reason for the -n part of the version number. It tells (I guess) the ABI version number for that kernel. As long as the ABI is still kept the package name can remain.</div>
<div>6) The same thing as in 4) above applies for custom build kernel modules done by the system administrator. This time it reduce the work for the system admin to build their custom modules as ABI compatibility is known by package name.</div>
<div><br></div><div>I do not think the error message:<br><span style="font-family:arial,sans-serif;font-size:13px">"Some packages can not be updated, because they require other</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">packages that are not installed on your system. You might use</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">apt-get dist-upgrade to work around that"</span><br style="font-family:arial,sans-serif;font-size:13px">
</div><div><span style="font-family:arial,sans-serif;font-size:13px">is something that we should have as an argument. It is not really an error message, and in some cases it is a good thing to get an extra reminder that something large is on the way.</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">I agree that the "old scheme" is better in case the kernel is not that well tested. If it is well tested then it is not really a problem.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">On the other hand point 6) above is an argument for the "new scheme".</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">I do not think point 2), 3) and 4) is something that applies to the openvz kernels. They should not be a problem.</span></div>
<div><br></div><div>Kir: But you need to consider point 5 and make sure that you make a new package name each time the ABI compatibility is broken.</div><div><br></div><div>I do not want to vote for either scheme, both are good, but in different ways.</div>
<div><br></div><div>Cheers,</div><div><br></div><div>// Ola</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 7, 2014 at 9:23 AM, Kir Kolyshkin <span dir="ltr"><<a href="mailto:kir@openvz.org" target="_blank">kir@openvz.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
<div>On 03/06/2014 06:13 PM, spameden wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi<br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2014-03-07 5:28 GMT+04:00 Kir
Kolyshkin <span dir="ltr"><<a href="mailto:kir@openvz.org" target="_blank">kir@openvz.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<div>On 03/02/2014 02:01 PM, spameden wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2014-03-03 0:38
GMT+04:00 Ola Lundqvist <span dir="ltr"><<a href="mailto:ola@inguza.com" target="_blank">ola@inguza.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Hi
<div><br>
</div>
<div>Problem fixed now.</div>
<div>I had fixed the problem temporarily,
but I had forgotten to upgrade to the
debarchiver version with the fix so it
will not happen again. Now I have done
the upgrade and fixed the problem
properly.</div>
</div>
</blockquote>
<div><br>
</div>
<div>I think it's not fixed properly:<br>
<br>
</div>
<div>1) wrong version of linux-image:<br>
</div>
<div># dpkg -l|grep linux-image-openvz<br>
</div>
<div>ii
linux-image-openvz-amd64
042+1 amd64
OpenVZ Linux kernel (meta-package) <br>
<br>
</div>
<div>2) # ls /boot |grep openvz<br>
config-2.6.32-openvz-042stab084.17-amd64<br>
<b>config-2.6.32-openvz-amd64</b><br>
initrd.img-2.6.32-openvz-042stab084.17-amd64<br>
<b>initrd.img-2.6.32-openvz-amd64</b><br>
System.map-2.6.32-openvz-042stab084.17-amd64<br>
<b>System.map-2.6.32-openvz-amd64</b><br>
vmlinuz-2.6.32-openvz-042stab084.17-amd64<br>
<b>vmlinuz-2.6.32-openvz-amd64</b><br>
<br>
</div>
<div>so now we are missing usual version here
in the package.. that's actually very bad
... can you look into it?<br>
<br>
</div>
<div>many thanks.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
This is intentional, and I changed it after looking into
how default Debian kernel is packaged/versioned.<br>
<br>
If you take a look, they have [meta]package
linux-image-amd64 which requires<br>
package linux-image-3.2.0-4-amd64. The latter
(currently) has a version of<br>
3.2.54-2 and this version is changed (incremented) with
every release, while<br>
package name stays the same (linux-image-3.2.0-4-amd64).
Also, vzkernel<br>
name stays the same -- it is /boot/vmlinuz-3.2.0-4-amd64
in different versions.<br>
I am using the very same approach now for OpenVZ
kernels.<br>
</div>
</blockquote>
<div><br>
</div>
<div>I understand your position. I checked how it's done in
Debian and yes you're right, they're using this scheme for
their mainline 3.2.0-4 kernel.<br>
<br>
</div>
<div>Tbh, I don't like their "NEW" way at all. <br>
</div>
<div><br>
</div>
<div>Here is why:<br>
</div>
<div><br>
</div>
<div>When new version of OpenVZ kernel comes its hard to
have 2 different kernels on the system (with different
versions).<br>
<br>
</div>
<div>Here is a simple scenario:<br>
<br>
</div>
<div>1) new kernel comes and it's not working at all on
certain configurations. <br>
<br>
2) if you configured grub correctly it would boot
previously working kernel after reboot.<br>
</div>
<div><br>
</div>
<div>--> But it wont boot previous OpenVZ kernel version,
because when you upgrade you overwrite existing kernel and
you need to rollback to the previous version manually.<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
Previously I was adding the VZ version (i.e.
042stab0xy.z) into kernel package name,<br>
and it was added to vmlinuz and the /lib/modules
directory name as well. </div>
</blockquote>
<div><br>
</div>
<div>I really liked how it was done before. There was an
option to leave certain kernel versions for testing as
well and delete what is not needed.<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">The problem<br>
is, you need to specify a different dependency in
linux-image-openvz-amd64 metapackage,<br>
and apt-get upgrade complains that it can't upgrade the
system since a new version<br>
of an installed package (linux-image-amd64) requires a
package that is not installed yet.<br>
The problem could be fixed by running dist-upgrade, but
eventually I decided that<br>
this message is a hint that I package openvz kernels
improperly, that lead me to<br>
looking into a way standard Debian kernels are packaged
and implementing it<br>
the same way for OpenVZ kernels.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Interesting.. I never seen myself such problem before.
It worked just fine for me for a long time (before there
was a problem with chksums). <br>
</div>
</div>
</div>
</div>
</blockquote>
<br></div></div>
The error from apt-get update was something like this<br>
(sorry I don't have exact message):<br>
<br>
"Some packages can not be updated, because they require other<br>
packages that are not installed on your system. You might use<br>
apt-get dist-upgrade to work around that"<br>
<br>
So I started to look why this is not happening with stock Debian
kernels<br>
and found out that I was doing it all wrong (or so I thought at that
time).<br>
<br>
We can surely revert back to the old packaging scheme...<div class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
I am not a Debian guru and am very open to suggestions
on how to improve this.<br>
Perhaps we can return to the older versioning scheme and
ask people to use dist-upgrade.<br>
Or maybe I am totally missing something. Please help.<span><font color="#888888"><br>
</font></span></div>
</blockquote>
<div><br>
</div>
<div>Yes, old way was really cool and convinient personally
for me on production environment. And for testing new
stable kernel versions too.<br>
<br>
</div>
<div>Of course there is a drawback that you need to cleanup
old kernel versions manually, cuz your /boot partition
must have some free space for future upgrades.<br>
<br>
</div>
<div>If OpenVZ kernels are very well tested before going to
stable versions I wouldnt mind NEW way. It's probably more
proper to have just 1 OpenVZ kernel version and update it
from time to time..<br>
</div>
</div>
</div>
</div>
</blockquote>
<br></div>
This is what we do with stable kernels -- they are released about
once a month,<br>
and we test a lot before releasing those. But yeah, maybe we should
just revert<br>
back to the old scheme.<br>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div><div><font face="courier new, monospace" size="1"> --- Inguza Technology AB --- MSc in Information Technology ----</font></div><div><font face="courier new, monospace" size="1">/ <a href="mailto:ola@inguza.com" target="_blank">ola@inguza.com</a> Annebergsslingan 37 \</font></div>
<div><font face="courier new, monospace" size="1">| <a href="mailto:opal@debian.org" target="_blank">opal@debian.org</a> 654 65 KARLSTAD |</font></div><div><font face="courier new, monospace" size="1">| <a href="http://inguza.com/" target="_blank">http://inguza.com/</a> Mobile: +46 (0)70-332 1551 |</font></div>
<div><font face="courier new, monospace" size="1">\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /</font></div><div><font face="courier new, monospace" size="1"> ---------------------------------------------------------------</font></div>
</div><div><br></div></div>
</div>