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 E1E63198005 for ; Wed, 27 Feb 2013 12:49:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 27D19E085D; Wed, 27 Feb 2013 12:49:53 +0000 (UTC) Received: from juliette.telenet-ops.be (juliette.telenet-ops.be [195.130.137.74]) by pigeon.gentoo.org (Postfix) with ESMTP id 3F687E0853 for ; Wed, 27 Feb 2013 12:49:52 +0000 (UTC) Received: from localhost ([94.226.55.127]) by juliette.telenet-ops.be with bizsmtp id 5Qpp1l01t2khLEN06Qppqr; Wed, 27 Feb 2013 13:49:50 +0100 Date: Wed, 27 Feb 2013 13:49:52 +0100 From: Tom Wijsman To: gentoo-kernel@lists.gentoo.org Subject: Re: [gentoo-kernel] Which Kernel? Message-ID: <20130227134952.3a6f8bec@gentoo.org> In-Reply-To: <1472354.HGzHXtoys4@bart> References: <20130226191318.2fec648c@gentoo.org> <1472354.HGzHXtoys4@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_/Uza/lKLZEP11L9f=r3ElmkC"; protocol="application/pgp-signature" X-Archives-Salt: 9bfb9ac9-dc0d-4c9b-be05-33d42a3ccb69 X-Archives-Hash: 455a67a4db91cd685a3c5fb0a9cd9f22 --Sig_/Uza/lKLZEP11L9f=r3ElmkC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 27 Feb 2013 13:07:38 +0100 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. 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. 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. > 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 Doing this once per branch or for each version is a big difference. =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. As stated above, that doesn't allow you to reproduce them quickly. > Then, I think using SLOTs for single versions is not really what > SLOTs are made for. From what I understand, for a *single* > *particular* version of any package you have ATOMs in portage and for > a branch or a group of versions that belong together somehow you have > SLOTs. Quoting `man 5 ebuild`: SLOT This sets the SLOT for packages that may need to have versions co-exist. It does not say anything about branches or groups, it actually states versions. There are use cases where people want 3.7.8 and 3.7.9 to co-exist, the thread root gives such an example (pending nvidia patch). 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. > I personally would like to see this scheme for kernels too. Be it > gentoo- sources or hardened-sources. All kernels share this SLOT syntax, it is implemented in the eclass. This is for the eclass maintainers to decide, but they will likely depend their decision on what all the eclass users think about that; the other option is moving it to the ebuild but that approach leads to inconsistency which is probably not a good idea. 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_/Uza/lKLZEP11L9f=r3ElmkC Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBAgAGBQJRLgDwAAoJEJWyH81tNOV9Pw8H/icoM141GmVz8zR+DHfhsYDs mxUTPo0E+9JY4Yrrpsbun9cKFNYTJ1ce4sWHI+MfraamTq0eOjoTtbnUTZQ5AkfB RQtmi1Y2uke7RMEurB8cg4/mJtm6ws3KiFYvEeVJr6tCRF2l+CneVK/qHJN+0kRu wdTwhIFqMDyOCgkf9HWIZfdEIwahJroXPSa/K+vV9/f3RHtXyXon3F9jTyin+qco 2pjOuOsAsrErFvboHM2b90DiCIv/WdBQIL5wCtxtenvpDr3+zkTJx7GnOYvuTLXL 9NI3DpyZWhZC1jShvfpKfINAdsbh9YB9qGh4MauNcnxsfi4pkfF9LLtJXe2pFzA= =akzn -----END PGP SIGNATURE----- --Sig_/Uza/lKLZEP11L9f=r3ElmkC--