From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A0B32198005 for ; Wed, 27 Feb 2013 16:24:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A6C17E090E; Wed, 27 Feb 2013 16:24:42 +0000 (UTC) Received: from gerard.telenet-ops.be (gerard.telenet-ops.be [195.130.132.48]) by pigeon.gentoo.org (Postfix) with ESMTP id AEF2FE08FC for ; Wed, 27 Feb 2013 16:24:41 +0000 (UTC) Received: from localhost ([94.226.55.127]) by gerard.telenet-ops.be with bizsmtp id 5UQg1l00E2khLEN0HUQgZU; Wed, 27 Feb 2013 17:24:40 +0100 Date: Wed, 27 Feb 2013 17:24:39 +0100 From: Tom Wijsman To: gentoo-kernel@lists.gentoo.org Subject: Re: [gentoo-kernel] Which Kernel? Message-ID: <20130227172439.6679b0c8@gentoo.org> In-Reply-To: <8109280.XIVqCWWA1E@bart> References: <1472354.HGzHXtoys4@bart> <20130227134952.3a6f8bec@gentoo.org> <8109280.XIVqCWWA1E@bart> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-kernel@lists.gentoo.org Reply-to: gentoo-kernel@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/sKrWTd1J_ji1R1KGUq9XDuW"; protocol="application/pgp-signature" X-Archives-Salt: 6f69cf25-1a6d-44d7-90ea-fe466abcb071 X-Archives-Hash: 7851e5bd3446f60d0cf9de3c34fe93d1 --Sig_/sKrWTd1J_ji1R1KGUq9XDuW Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 27 Feb 2013 16:39:22 +0100 Marc Schiffbauer wrote: > Am Mittwoch, 27. Februar 2013, 13:49:52 schrieb Tom Wijsman: > > On Wed, 27 Feb 2013 13:07:38 +0100 > >=20 > > Marc Schiffbauer wrote: > > > Am Dienstag, 26. Februar 2013, 19:13:18 schrieb Tom Wijsman: > > > > On Tue, 26 Feb 2013 18:37:16 +0100 (CET) > > > >=20 > > > > As an easy way to keep a single kernel version from being > > > > unmerged by a kernel upgrade in Portage, I think. > > > >=20 > > > > emerge gentoo-sources:3.7.9 > > >=20 > > > But why would you want that? I think normally its more likely > > > that a user wants to stick to the seriens (e.g. :3.7) so that > > > he/she receives security updates as well as minor fixes. > >=20 > > Because when sources unmerge, nothing can build against them and you > > also can't do a quick recompile if you do not want to do an upgrade. >=20 > Indeed. But I thought of it only as a backup so that you can boot > your system in case a newer kernel won't. >=20 > Why would you want to continue to use an outdated/insecure kernel > *from the same series* like 3.7*? No time yet to recompile a new kernel, a temporarily broken newer kernel (eg. nvidia-drivers doesn't work with it yet), and so on... Just one version off doesn't make that much of a difference in date and security. > > The majority of users doesn't upgrade on every single release, it is > > better to support them in their upgrade schedule instead of forcing > > them to upgrade or use more complex approaches to do what they want. >=20 > Where would be the force? Uninstall of old sources would happen while > they are upgrading. It doesn't copy the sources, rebuild and install the kernel though. > I guess you are referring to a use case where user just upgrade > packages but would not like to restart the system. This is indeed a > use case for exact version slots. More is needed than to just restart their system, see my previous sentence. > Maybe both things yould coexist? Why not have both kinds of SLOTs > then? Hmm, subslots definitely sound interesting to use; only needs to figure out if that fits the case and whether users will understand them. > > > If you really wanted to stick to a particular version you can > > > always mask any version greater than that similar to what you > > > wrote yourself below: > > >=20 > > > echo ">=3Dsys-kernel/gentoo-sources-3.7" > > > >> /etc/portage/package.mask > >=20 > > Doing this once per branch or for each version is a big difference. >=20 > Indeed. The above mask would allow all 3.6* kernels rigtht? Assuming the version syntax doesn't get an extension that would undermine the version number, that masks everything in 3.7 and newer. > >=20 > > > First, if you remove any gentoo-sources package it will never > > > remove the kernel or modules that have been built from it. So you > > > will always keep the kernel that may be important if a newer one > > > has problems for example. Regardless of removing the sources or > > > not. > >=20 > > As stated above, that doesn't allow you to reproduce them quickly. >=20 > That was not my intention. Please see above. But it can be the intention of other users. > >=20 > > For small packages, it doesn't really matter how you do it; but > > setting up the kernel (copy config, make oldconfig) and compiling it > > make explicit (un)masking much more annoying than just keeping > > multiple versions within a branch around. >=20 > Sorry I do not get it. What is your point here? Getting minor kernel > updates automatically without having to fiddle with masks/unmaks each > time is the goal here IMO. I'm not sure which part you didn't get, but be aware that the suggested SLOT approach does not keep multiple versions within a branch around; which forces the user to upgrade and therefore requires the user to do all that I said. Kernels release way too often for that, and it is not guaranteed that newer versions work so users will have to try them first; if one breaks for them, the new SLOT approach would have removed their old sources and therefore they would have to start all over with them if they have the need to rebuild their kernel or compile something against them. There is more than a single goal when talking about changing the SLOT syntax, especially for a bigger package like the kernel; users use it differently, yielding different reasons for different approaches to specify which version are selected and which versions are masked. Changing the SLOT syntax makes you need to consider what else changes, because it's not really worth pulling off something for a few users when it breaks the work flow for the majority of users. And note, we're pitting of only two or three use cases here, there are possibly more of them; I would love to see some regulars join the discussion. =20 > So how about just add a new SLOTs for every stable long term kernel > release series like "3.4" and leaving current SLOTs as they are? Hmm, since stable kernel releases break less often, this might be reasonable. This introduces some inconsistency though, although that could be abused to make it clear to users that they are LTS series. I'll try to hear, I need to bug them about 3.4.3x stabilization too. With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D --Sig_/sKrWTd1J_ji1R1KGUq9XDuW Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBAgAGBQJRLjNKAAoJEJWyH81tNOV9HrAIAKlcWTAgr1r0ELVYzU52P6h0 J8mtAsvrn58QfBlvCPIHBoka8cwLwYC8y7RjLEEWgIFNF6sFuPdarVBZekT7od15 L9B3exbxw4jqyP9EACUJgdbQEHDXdPhm+vlVeMTwIuW2QJpHyBYRiYx9YeU7y0nL TS7s70YKTdiOKg3oV/O1t1spFcCh9EX9KWKcm89T1MsHiHMJnKYImaMTEcmKTc8I tVsGB7r9nFhhtl7VWb58Fg1cYq8S0KafJL5pcpy3GJsSSOiPsCVbsrM1knOybvGM Pt5ztg6bGGZ5RCthDAaof6boDbeZ2Qk/ESP+9yXjZOiyVpcNmUp5Z1fdSxt6xvs= =SUF8 -----END PGP SIGNATURE----- --Sig_/sKrWTd1J_ji1R1KGUq9XDuW--