# how to keep two trees for the same kernel in /usr/src

## aCOSwt

Let's say that I would like to keep together in my /usr/src :

A tree for xyzt-sources-V.R.B emerged -deblob

And another one for the same xyzt-sources-V.R.B but emerged +deblob.

How can I simply achieve this, I mean apart from fiddling the ebuild's name ?

I must have missed some portage's automagic way to force the slotting !

----------

## Hypnos

Well, the problem is that they are in fact in the same slot, and slots are independent of USE flags.

Instead of fiddling with the ebuild name, you could fiddle with the slot #.

I'm also curious whether there's a better solution.

----------

## ppurka

You could emerge with -deblob, and then "cp -a /usr/src/linux-... /usr/src/linux-...-deblob". Then emerge with +deblob, and then portage will keep track of the original directory, but not the directory with -deblob at the end. Since each kernel source is actually isolated into it's own directory in /usr/src, it is no hassle to get rid of the -deblob kernel once you decide to not keep it.

----------

## Hypnos

 *ppurka wrote:*   

> You could emerge with -deblob, and then "cp -a /usr/src/linux-... /usr/src/linux-...-deblob". [...]

 

Why would you use "cp -a" instead of "mv" ?

----------

## cwr

/usr/src/linux is generally a link to the current linux kernel tree, whose directory

has the full kernel name.  You can have several kernel trees under /usr/src.

It would seem easier to tinker with the link that with the actual source directory.

Will

----------

## aCOSwt

 *ppurka wrote:*   

> You could emerge with -deblob, and then "cp -a /usr/src/linux-... /usr/src/linux-...-deblob". Then emerge with +deblob, and then portage will keep track of the original directory, but not the directory with -deblob at the end. Since each kernel source is actually isolated into it's own directory in /usr/src, it is no hassle to get rid of the -deblob kernel once you decide to not keep it.

 

Oh yes OK, I can also fiddle directory names but I really would like to avoid this. To avoid any kind of fiddling.

Because this is not really for my personal usage. I do not emerge my kernels anyway.

So my question is from the standard user standpoint. One emerging his kernels the canonical way that is to say one willing to avoid any fiddling.

 *Hypnos wrote:*   

> Well, the problem is that they are in fact in the same slot, and slots are independent of USE flags.

 

That is something like that I would look for.

Is there a more or less automagic possibility given to the standard user when emerging a kernel, enabling the installation in a /usr/src subdirectory which name would be useflag dependent ?

----------

## Genone

No. The name of the installation directory is controlled by the ebuild, and kernel-2.eclass doesn't support user-configurable install directories.

----------

## aCOSwt

 *Genone wrote:*   

> No. The name of the installation directory is controlled by the ebuild, and kernel-2.eclass doesn't support user-configurable install directories.

 

All right then :

From a Gentoo policy standpoint : Must all the gentoo supported kernel ebuilds rely on the kernel-2.eclass ?

----------

## ppurka

 *Hypnos wrote:*   

>  *ppurka wrote:*   You could emerge with -deblob, and then "cp -a /usr/src/linux-... /usr/src/linux-...-deblob". [...] 
> 
> Why would you use "cp -a" instead of "mv" ?

 Because portage will try to remove the old files when you re-emerge with +deblob. I wasn't sure how portage would handle missing files; essentially the whole previous installation.

----------

## Hypnos

 *ppurka wrote:*   

>  *Hypnos wrote:*   Why would you use "cp -a" instead of "mv" ? Because portage will try to remove the old files when you re-emerge with +deblob. I wasn't sure how portage would handle missing files; essentially the whole previous installation.

 

According to the Package Management Standard this behavior is undefined, but Paludis just declares the file "gone" and proceeds without error.  I would be very surprised if Portage acted differently.

----------

## Genone

 *aCOSwt wrote:*   

>  *Genone wrote:*   No. The name of the installation directory is controlled by the ebuild, and kernel-2.eclass doesn't support user-configurable install directories. 
> 
> All right then :
> 
> From a Gentoo policy standpoint : Must all the gentoo supported kernel ebuilds rely on the kernel-2.eclass ?

 

Well, I don't know current policies, but if you want this feature it'd make more sense to request this as an enhancement to kernel-2.eclass rather than avoiding it (I was just stating the current situation, not that it has to be that way). Mind that a proper implementation is likely more tricky than it seems to you, as I guess it would require USE-aware SLOT settings. And personally I don't really see the use case for this.

----------

## aCOSwt

 *Genone wrote:*   

> it'd make more sense to request this as an enhancement to kernel-2.eclass rather than avoiding it

 

Will do !

 *Genone wrote:*   

> Mind that a proper implementation is likely more tricky than it seems to you, as I guess it would require USE-aware SLOT settings.

 

It had already seemed tricky to me... so if you say it'd be more... I... give up !   :Very Happy: 

 *Genone wrote:*   

> And personally I don't really see the use case for this.

 

I agree that if we consider the sole deblob, the use case is rather limited. But I was thinking of other possible use flags. Flags enabling different patchsets being an example. In these cases, the user might want to keep different instances for comparison purposes.

----------

## toralf

A different approach than using portage to handle the kernel sources would be something like this 

```
tfoerste@n22 ~ $ cat /etc/portage/profile/package.provided

sys-kernel/vanilla-sources-3.4.10

sys-kernel/vanilla-sources-3.5.3

```

You can then completely manage your own source trees there.

----------

## cwr

 *ppurka wrote:*   

>  *Hypnos wrote:*    *ppurka wrote:*   You could emerge with -deblob, and then "cp -a /usr/src/linux-... /usr/src/linux-...-deblob". [...] 
> 
> Why would you use "cp -a" instead of "mv" ? Because portage will try to remove the old files when you re-emerge with +deblob. I wasn't sure how portage would handle missing files; essentially the whole previous installation.

 

An ordinary emerge gentoo-sources leaves the old sources in place - at least it always has for me.

It just switches the /usr/src/linux link to the new source directory.

Will

----------

## Hypnos

 *cwr wrote:*   

> An ordinary emerge gentoo-sources leaves the old sources in place - at least it always has for me.
> 
> It just switches the /usr/src/linux link to the new source directory.

 

Only if the version is different.

The OP is asking about keeping two trees with the same version, just different USE flags.

----------

