# gentoo kernel slots

## josephg

it would be so much simpler to have sys-kernel/gentoo-sources:4.4 or sys-kernel/gentoo-sources:4.9 in my world.. but that doesn't work. it seems i have to have sys-kernel/gentoo-sources:4.4.87-r1 or sys-kernel/gentoo-sources:4.9.49-r1 in my world, which becomes too specific. and then they don't get updated.. because that is the only package in that slot.

why don't gentoo kernel maintainers create a slot for major versions, as opposed to each bugfix release?

----------

## krinn

You'll won't specially be happy to have sources for 4.4.20 and not really happy to have your current 4.4.19 sources gone.

----------

## fedeliallalinea

I think because with only major slot current kernel sources installed would be uninstalled

----------

## josephg

 *krinn wrote:*   

> You'll won't specially be happy to have sources for 4.4.20 and not really happy to have your current 4.4.19 sources gone.

 

if i have gentoo-sources:4.4 in world, i would expect the whatever current stable version if that be 4.4.20 to be installed on update.

if i wanted to keep 4.4.19 package, i would have gentoo-sources-4.4.19 in my world. isn't that just like any other package, say python? 

your current kernel sources aren't automatically uninstalled. wiki says that you have to manually remove them, which is my experience too.

and if i want to keep a specific kernel package installed, i'd have that package-version in my world. isn't that the gentoo way?

----------

## fedeliallalinea

Portage, for all packages, remove all file listed in /var/db/pkg/category/package/CONTENTS when you update a package not slotted.

----------

## josephg

 *fedeliallalinea wrote:*   

> Portage, for all packages, remove all file listed in /var/db/pkg/category/package/CONTENTS when you update a package not slotted.

 

if i have a specific package-version in my world for example sys-kernel/gentoo-sources-4.9.49-r1, would portage remove all those files when sys-kernel/gentoo-sources updates to 4.9.76?

http://wiki.gentoo.org/wiki/Kernel/Removal#Protecting_kernel_sources

i want to protect like sys-kernel/gentoo-sources:4.4 rather than sys-kernel/gentoo-sources-4.4.87-r1

----------

## krinn

 *josephg wrote:*   

> your current kernel sources aren't automatically uninstalled. wiki says that you have to manually remove them, which is my experience too.

 

because they don't use the same slot  :Smile: 

----------

## josephg

what is (or should be) the difference between sys-kernel/gentoo-sources:4.9, sys-kernel/gentoo-sources:4.9.49-r1 and sys-kernel/gentoo-sources-4.9.49-r1?

----------

## krinn

 *josephg wrote:*   

> what is (or should be) the difference between sys-kernel/gentoo-sources:4.9, sys-kernel/gentoo-sources:4.9.49-r1 and sys-kernel/gentoo-sources-4.9.49-r1?

 

Like that, you could think none or little, in real it could be huge, the -r1 could have a big or important patch the non -r1 lack.

----------

## josephg

yes that is why i want to have something like sys-kernel/gentoo-sources:4.4 rather than sys-kernel/gentoo-sources:4.4.87-r1 in my world. i can have sys-kernel/gentoo-sources-4.4.87-r1 in my world, if i want to keep that specifically.

----------

## krinn

you can have gentoo-sources-version and gentoo-sources both in world if you want latest while keeping one protect.

----------

## josephg

 *krinn wrote:*   

> you can have gentoo-sources-version and gentoo-sources both in world if you want latest while keeping one protect.

 

that doesn't work on my gentoo  :Sad: 

```
$ sudo emerge gentoo-sources-4.9

!!! 'gentoo-sources-4.9' is not a valid package atom.

!!! Please check ebuild(5) for full details.

$ sudo emerge sys-kernel/gentoo-sources-4.9

!!! 'sys-kernel/gentoo-sources-4.9' is not a valid package atom.

!!! Please check ebuild(5) for full details.

$ sudo emerge =sys-kernel/gentoo-sources-4.9

These are the packages that would be merged:

Calculating dependencies... done!

emerge: there are no ebuilds to satisfy "=sys-kernel/gentoo-sources-4.9".

$
```

----------

## josephg

same for lts 4.4

```
# emerge sys-kernel/gentoo-sources-4.4

!!! 'sys-kernel/gentoo-sources-4.4' is not a valid package atom.

!!! Please check ebuild(5) for full details.

# emerge sys-kernel/gentoo-sources:4.4

These are the packages that would be merged:

Calculating dependencies... done!

emerge: there are no ebuilds to satisfy "sys-kernel/gentoo-sources:4.4".

#
```

----------

## khayyam

 *josephg wrote:*   

> 
> 
> ```
> !!! 'gentoo-sources-4.9' is not a valid package atom.
> ```
> ...

 

josephg ... because you're not providing a valid atom:

```
# emerge -pvq '=sys-kernel/gentoo-sources-4.9*'

[ebuild  N    ] sys-kernel/gentoo-sources-4.9.76  USE="-build -experimental -symlink"
```

I've read the thread but I'm not clear on the problem ... what is it you're trying to solve?

best ... khay

----------

## josephg

 *khayyam wrote:*   

> I've read the thread but I'm not clear on the problem ... what is it you're trying to solve?

 

i want stable lts kernels 4.4 and 4.9 in world

when i had gentoo-sources in my world, i got 4.12 (which corrupted my btrfs filesystem) and then 4.14 which was not enough tried & tested.

----------

## khayyam

 *josephg wrote:*   

>  *khayyam wrote:*   I've read the thread but I'm not clear on the problem ... what is it you're trying to solve? 
> 
> i want stable lts kernels 4.4 and 4.9 in world

 

josephg ... "in world"? You mean in package.accept_keywords? What difference does those being in world make? That is what I didn't understand from the above. 

```
=sys-kernel/gentoo-sources-4.4*

=sys-kernel/gentoo-sources-4.9*
```

```
# emerge -pvq '=sys-kernel/gentoo-sources-4.4*' '=sys-kernel/gentoo-sources-4.9*'

[ebuild  N    ] sys-kernel/gentoo-sources-4.4.111  USE="-build -experimental -symlink"

[ebuild  N    ] sys-kernel/gentoo-sources-4.9.76  USE="-build -experimental -symlink

# emerge -pvq sys-kernel/gentoo-sources

[ebuild  N    ] sys-kernel/gentoo-sources-4.9.76  USE="-build -experimental -symlink"
```

Does that solve the problem?

HTH & best ... khay

----------

## josephg

 *khayyam wrote:*   

> 
> 
> ```
> =sys-kernel/gentoo-sources-4.4*
> 
> ...

 

so adding these two lines as above will ensure portage will keep 4.4 and 4.9 updated, for example when a new 4.9.* stable is released? do i remove gentoo-sources from world? thank you

----------

## josephg

just to clarify, i don't want ~x86 versions. only stable please.

----------

## Hu

It looks to me like josephg is confusing several related but distinct concepts.

josephg: your world file controls which packages are exempt from --depclean and guides some forms of general upgrade.  The package slot controls which package versions Portage permits to be co-installed.  If the kernel sources were slotted at the patch series level (:4.4) instead of the version specific level (:4.4.87-r1), then emerge --oneshot =sys-kernel/gentoo-sources-4.4.110 would automatically emerge --unmerge all other gentoo-sources-4.4*.  You would not be given a choice in the matter.  You would not be permitted to have installed and under Portage control two separate 4.4.x kernels, because their common SLOT of :4.4 would tell Portage that it's not supported to do so.

If you don't want unstable versions, don't use package.accept_keywords.

----------

## khayyam

 *josephg wrote:*   

>  *khayyam wrote:*   
> 
> ```
> =sys-kernel/gentoo-sources-4.4*
> 
> ...

 

josephg ... as you can see from the above output those keywords correspond to 4.4.111 and 4.9.76 currently (both of which are keyworded 'stable'), and would be updated should the package(s) be bumped. But is that what you want, do you want these to be selected only if keyworded stable? 

```
=sys-kernel/gentoo-sources-4.4* amd64

=sys-kernel/gentoo-sources-4.9* amd64
```

 *josephg wrote:*   

> [...] do i remove gentoo-sources from world? thank you

 

No, because 'sys-kernel/gentoo-sources' (notice no anchor to -<version>) would correspond to the package, and you've explictly emerged that package. If you need to have these in the world file to prevent depcleaning then you need to stipulate the exact version(s) ... that said, I've never attempted to use a wildcard in the world file, it doesn't error, I just tested, but I'm not sure what happens in terms of selection.

EDIT: actually, 'amd64' would simply give you what you would get with 'emerge --update @world', so I still don't understand what the problem was previously. 

best ... khay

----------

## josephg

 *Hu wrote:*   

> You would not be permitted to have installed and under Portage control two separate 4.4.x kernels, because their common SLOT of :4.4 would tell Portage that it's not supported to do so.

 

thank you for explaining Hu. i can understand now why every single version is in it's own unique slot.

 *khayyam wrote:*   

> so I still don't understand what the problem was previously

 

i'll tell you what happened to me. i had gentoo-sources in my world. i track stable x86, not ~x86. long long ago, 4.12 was released and i got the update. i installed 4.12 and had severe ath9k and btrfs problems, and ended up migrating/recovering my data. as i didn't want 4.12 or above, i uninstalled gentoo-sources and added gentoo-sources:4.9.49 to world, which meant i missed the 4.9.69, and later stable updates.

today 4.9 got another stable update to 4.9.76. hence why i wondered if there had been a 4.9 slot, i would continue receiving 4.9 updates. now i understand that is not feasible, and to keep an eye out for each minor version.

----------

## Hu

For your use case, you could add a version-unqualified atom to world, then package.mask the major series that fail for you (=sys-kernel/gentoo-sources-4.12*, etc.).  Just be aware that this will eventually leave you without any unmasked supported kernels.

----------

## josephg

 *Hu wrote:*   

> For your use case, you could add a version-unqualified atom to world, then package.mask the major series that fail for you (=sys-kernel/gentoo-sources-4.12*, etc.)

 

i have now masked >=gentoo-sources-4.10

i didn't know we could use * like that. thanks to you Hu and khay.

 *Hu wrote:*   

> Just be aware that this will eventually leave you without any unmasked supported kernels.

 

i plan to stick with lts 4.9 till they release the next lts after 4.14. hopefully 4.14 might stabilise by then.

4.4 eol 2022! that eventuality might be a while..  :Wink: 

----------

## khayyam

 *josephg wrote:*   

>  *khayyam wrote:*   so I still don't understand what the problem was previously 
> 
> i'll tell you what happened to me. i had gentoo-sources in my world. i track stable x86, not ~x86. long long ago, 4.12 was released and i got the update. i installed 4.12 and had severe ath9k and btrfs problems, and ended up migrating/recovering my data. as i didn't want 4.12 or above, i uninstalled gentoo-sources and added gentoo-sources:4.9.49 to world, which meant i missed the 4.9.69, and later stable updates.

 

josephg ... you have to consider this, how would you know prior to testing if ('stable') 4.12 (or 4.14, or in fact any kernel) would cause such issues? So, what are you trying to protect against? It's quite possible that 4.9.x, or 4.4.x, will exhibit similar behavior (or some problem).

 *josephg wrote:*   

> today 4.9 got another stable update to 4.9.76. hence why i wondered if there had been a 4.9 slot, i would continue receiving 4.9 updates. now i understand that is not feasible, and to keep an eye out for each minor version.

 

=sys-kernel/gentoo-sources-4.9.76 is currently the highest 'stable' package. As Hu suggests you can mask the offending package, or series, but doing this isn't going to protect you from the kind of issues you encounted, because you don't know what breakage, of fixes, come with the next 4.4.x, 4.9.x, 4.12.x, 4.14.x. Anyhow, your 4.12* mask:

```
=sys-kernel/gentoo-sources-4.12*
```

BTW, I think you're still a little confused about the world file, re-read what Hu wrote above.

best ... khay

----------

## josephg

 *khayyam wrote:*   

> BTW, I think you're still a little confused about the world file, re-read what Hu wrote above

 

yes i did that. now i have sys-kernel/gentoo-sources in world, and >=sys-kernel/gentoo-sources-4.10 in package.mask. hopefully that should keep updated me on 4.9.x series.

----------

