| 1 |
On Wed, 29 Jan 2014 16:09:31 +0200, Thanasis <thanasis@××××××××××.org> |
| 2 |
wrote: |
| 3 |
> on 01/28/2014 10:12 PM eroen wrote the following: |
| 4 |
> > On Tue, 28 Jan 2014 21:29:21 +0200, Thanasis |
| 5 |
> > <thanasis@××××××××××.org> wrote: |
| 6 |
> >> Is there a way to specify that I want to install (emerge) the |
| 7 |
> >> latest 3.10.X series of sys-kernel/gentoo-sources as a slot, in |
| 8 |
> >> parallel with the latest gentoo-sources? |
| 9 |
> >> |
| 10 |
> >> Currently, that would be version 3.10.28. |
| 11 |
> >> I know I can specify it like so, |
| 12 |
> >> emerge =sys-kernel/gentoo-sources-3.10.28 |
| 13 |
> >> |
| 14 |
> >> but then it would not get "auto-updated" when a newer version of |
| 15 |
> >> that series (for example 3.10.29) becomes available in portage. |
| 16 |
> > |
| 17 |
> > Afaik there is no configuration-only way to do this, but you can |
| 18 |
> > make it happen by adding your own virtual ebuilds in a local |
| 19 |
> > overlay[1], say virtual/thanasis-sources, then adding that to world. |
| 20 |
> > |
| 21 |
> > You can make one ebuild for each kernel-series you want, each in its |
| 22 |
> > own slot, using the =cat/pkg-3.10* syntax for RDEPEND. Find |
| 23 |
> > attached a (barely tested) suggestion for |
| 24 |
> > virtual/thanasis-sources/thanasis-sources-3.10.ebuild . |
| 25 |
> |
| 26 |
> Thanks eroen, I tested it and it looks like it works. |
| 27 |
> |
| 28 |
> One caveat, |
| 29 |
> > =cat/pkg-3.10* also matches cat/pkg-3.107.1, |
| 30 |
> |
| 31 |
> I guess that kernel versions >= 3.100 are going to be in the tree, if |
| 32 |
> ever, probably in about a decade from now :P |
| 33 |
> |
| 34 |
> > which could become an |
| 35 |
> > issue if you wanted, say, the 3.2 series. |
| 36 |
> |
| 37 |
> Why would that be a problem? |
| 38 |
> In the ebuild, you specified the value |
| 39 |
> RDEPEND="=sys-kernel/gentoo-sources-${PV}*" |
| 40 |
|
| 41 |
I think you got it, but then I confused you with a poorly chosen |
| 42 |
example. The problem I referred to; if you try this exact method to |
| 43 |
follow the 3.2.x kernels, you will switch to 3.20.0 when that comes |
| 44 |
around. Similarly, it does not currently work with 3.1.x, and could |
| 45 |
eventually (in a very long time, like you commented :P ) break for |
| 46 |
other versions. |
| 47 |
|
| 48 |
It would be nice to have a better way to accomplish this, perhaps |
| 49 |
with some sort of world file variant supporting version ranges. That |
| 50 |
could also be more intuitive and less prone to unintended consequences |
| 51 |
(especially in the face of SLOTs) than package.mask-ing newer versions |
| 52 |
to keep an old version of something around. |
| 53 |
|
| 54 |
-- |
| 55 |
eroen |
Archives