# virtual - so langsam reichts aber wirklich

## schmidicom

Mich auf diese weise zu beschweren ist eigentlich nicht meine Art aber inzwischen habe sogar genug.

So langsam übertreiben es die Devs aber wirklich mit ihren virtuals. Erst bekommt udev sein eigenes virtual das mir fast ein downgrade reinwürgt und jetzt will mir ein weiteres virtual einen Kernel aus der Portage-Datenbank installieren obwohl ich durchaus in der Lage bin mich selbst darum zu kümmern.

Ist diese Gängelung echt nötig?

----------

## toralf

bzgl. des Kernels hilft vllt. etwas in dieser Art :

```
$ cat /etc/portage/profile/package.provided

sys-kernel/vanilla-sources-3.4.10

sys-kernel/vanilla-sources-3.5.3

```

Ansonsten sollte eher die Größe des portage trees an sich ein Grund zum Ärgernis sein als die paar zusätzlichen virtuals, oder ?

----------

## schmidicom

Dabei entstehen dummerweise zwei neue Probleme:

1. Dadurch müsste ich jedes sourcen ebuild einzeln in diese Datei eintragen und das auch noch nach jedem sync aufs neue.

2. Sobald diese Datei existiert funktioniert ufed nicht mehr und darauf kann/werde ich nicht verzichten.

Meine Lösung für diesen nervtöter sieht jetzt folgender massen aus:

```
slap ~ # cat /usr/local/portage/virtual/linux-sources/linux-sources-9999.ebuild 

# Copyright 1999-2012 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: /var/cvsroot/gentoo-x86/virtual/linux-sources/linux-sources-0.ebuild,v 1.7 2012/11/24 20:33:52 pacho Exp $

EAPI=2

DESCRIPTION="Virtual for Linux kernel sources"

HOMEPAGE=""

SRC_URI=""

LICENSE=""

SLOT="0"

KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 s390 sh sparc x86"

IUSE=""

DEPEND=""

RDEPEND=""
```

----------

## mv

 *schmidicom wrote:*   

> 1. Dadurch müsste ich jedes sourcen ebuild einzeln in diese Datei eintragen und das auch noch nach jedem sync aufs neue.

 

Weder noch.

Zum 1. Teil: Wenn eine der OR-Dependencies vorhanden ist, sind die Abhängigkeiten erfüllt. (Man könnte sich streiten, ob es angemessener wäre, direkt virtual/linux-sources-9999 einzutragen, aber das ist eher eine philosophische als eine praktisch relevante Überlegung.)

Zum 2. Teil: Nein, schau dir den Pfad mal an.

 *Quote:*   

> 2. Sobald diese Datei existiert funktioniert ufed nicht mehr und darauf kann/werde ich nicht verzichten.

 

Wie meinen? Was hat ufed mit Portage-Konfigurationsdateien zu tun?

----------

## mv

 *schmidicom wrote:*   

> Ist diese Gängelung echt nötig?

 

Je mehr virtuals, desto weniger Gängelung, weil Du dann verhältnismäßig schmerzlos das portage-Programm gegen Dein eigenes Ebuild austauschen kannst. Im Idealfall wären alle Ebuilds zusätzlich auch als Virtuals vorhanden.

----------

## schmidicom

In den meisten fällen haben die virtuals durchaus sinn aber hier wohl kaum. Ich habe zumindest noch kein Linux gesehen das ohne Kernel gestartet werden konnte und somit kann man wohl davon ausgehen das irgendein Kernel immer vorhanden ist.

Also wofür braucht es da ein virtual?

----------

## mv

 *schmidicom wrote:*   

> ch habe zumindest noch kein Linux gesehen das ohne Kernel gestartet werden konnte

 

kernel != kernel-sources.

Es geht um die Sourcen selbst, die z.B. zum Bauen von Modulen benötigt werden (und das geht vielleicht sogar unter BSD oder prefix).

Natürlich steht es Dir frei, die Sourcen unabhängig von portage zu installieren, genauso wie es Dir bei jedem anderen Paket auch freisteht, es unabhängig von portage zu installieren. Um portage mitzuteilen, dass Du das selber machen willst, gibt es die package.provided-Datei. Wieso sollten da die kernel-source-ebuilds eine Ausnahme machen?

----------

## toralf

 *mv wrote:*   

> Natürlich steht es Dir frei, die Sourcen unabhängig von portage zu installieren

 Genau das ist - anbei bemerkt - mein USE case. Ich habe sowohl Linus' tree als auch den stable tree ins selbe Repository gecloned und wende nun immer von dort die diffs auf /usr/src/linux-3.x.y an

----------

## bell

Meine Meinung ist auch dass die Virtuals was gutes sind. Dass jetzt eines für udev da ist, bedeutet für mich dass Gentoo sich auch für die SystemD-Udev Alternativen wie zB. dem Fork eudev öffnet. Somit bleibt die Qual der Wahl beim User, wie es bei Gentoo üblich ist.

zum Kernel: Da hat mv schon alles gesagt: kernel != kernel-sources (+1).

----------

## schmidicom

Die Gründe für das udev virtual kann ich ja noch teilweise nachvollziehen aber das für die Kernelsourcen nicht wirklich. Es wird wohl kaum einer unter Gentoo einen Kernel installieren und danach die Sourcen aus denen er gemacht wurde wieder löschen.

----------

## Josef.95

 *schmidicom wrote:*   

> In den meisten fällen haben die virtuals durchaus sinn aber hier wohl kaum. Ich habe zumindest noch kein Linux gesehen das ohne Kernel gestartet werden konnte und somit kann man wohl davon ausgehen das irgendein Kernel immer vorhanden ist.
> 
> Also wofür braucht es da ein virtual?

  Wie schon angemerkt geht es um die linux-sources, nicht um den Kernel selbst.

Mit dem virtual/linux-sources Paket soll doch nur sichergestellt werden das Sources als Abhängigkeit installiert werden, sofern denn benötigt. Welche Sources du letztendlich nutzen möchtest steht dir frei.

Schau dir das virtual/linux-sources Ebuild doch mal an ;)

Von Gängelung kann wirklich keine Rede sein - im gegenteil, dir bleibt mit dem virtual die freie Wahl :)

----------

## bell

Das Prinzip des Virtuals ist: Es muss IRGENDEINES der dort enthaltenen Pakete vorhanden sein. Somit hat virtual/linux-sources die Abhängigkeit erfüllt, EGAL welche Sources Du drauf hast. Wenn Du was eigenes nimmst, musst Du Portage über package.provided sagen "Ich habe was eigenes".

 *Quote:*   

> Es wird wohl kaum einer unter Gentoo einen Kernel installieren und danach die Sourcen aus denen er gemacht wurde wieder löschen.

 Wieso nicht? Wenn man den Speicherplatz braucht? zB. auf einem Live-Medium oder einem Embedded System? Es gibt auch Systeme, für die man lieber einen fertigen Kernel nimmt und selbst keinen baut, da man selbst nicht alle Patches zusammensuchen will oder zur Verfügung hat (Beispiel: Fritzbox), oder man traut sich nicht einen eigenen Kernel zu flashen und nutzt daher den bereits geflashten funktionierenden Kernel des Herstellers, oder oder oder. In all diesen Fällen hat man normalerweise keine Sources installiert, die ggf. zum Bauen bestimmter zusätzlicher Kernel-Module benötigt werden.

----------

## Schorchgrinder

gerade mal geschaut, bei mir ist das virtual/linux-sources nicht installiert bzw benötigt.

Sollte also irgend eine Paketabhängigkeit, die das Paket mit installieren will.

----------

## bell

Bei mir:

```
$ equery d virtual/linux-sources

 * These packages depend on virtual/linux-sources:

app-emulation/virtualbox-modules-4.2.4 (kernel_linux ? virtual/linux-sources)

app-emulation/vmware-modules-271.1 (kernel_linux ? virtual/linux-sources)

x11-drivers/nvidia-drivers-304.64 (kernel_linux ? virtual/linux-sources)

```

Die Sources werden zum Bauen von externen Modulen benötigt. Wenn Du keine externen Module bauen willst, benötigst Du auch keine Kernel-Sources.

----------

## mv

 *bell wrote:*   

> Die Sources werden zum Bauen von externen Modulen benötigt.

 

Wenn das Ganze mal konsequent in allen Modulen benutzt wird, könnte man damit vermutlich emerge @module-rebuild schneller implementieren. Kennt jemand ein Modul bei dem diese Abhängigkeit noch fehlt? Ansonsten könnte man das vielleicht mal als Feature Request an Portage melden...

----------

## Josef.95

 *mv wrote:*   

>  *bell wrote:*   Die Sources werden zum Bauen von externen Modulen benötigt. 
> 
> Wenn das Ganze mal konsequent in allen Modulen benutzt wird, könnte man damit vermutlich emerge @module-rebuild schneller implementieren. Kennt jemand ein Modul bei dem diese Abhängigkeit noch fehlt? Ansonsten könnte man das vielleicht mal als Feature Request an Portage melden...

 

Ist mit der aktuellen portage-2.1.11.31 Version nun auch in stable verfügbar :)

Ja, nach langem warten ist es nun endlich soweit - es sind nun standardmäßig folgende Sets in in der stable Version verfügbar: 

```
# emerge --list-sets

live-rebuild

module-rebuild

preserved-rebuild

selected

system

world

x11-module-rebuild
```

----------

## mv

 *Josef.95 wrote:*   

>  *mv wrote:*    *bell wrote:*   Die Sources werden zum Bauen von externen Modulen benötigt. 
> 
> Wenn das Ganze mal konsequent in allen Modulen benutzt wird, könnte man damit vermutlich emerge @module-rebuild schneller implementieren 
> 
> Ist mit der aktuellen portage-2.1.11.31 Version nun auch in stable verfügbar :)

 

Das ist ein Missverständnis: Mit "schneller implementieren" meinte ich, die bestehende Implementation zu beschleunigen: Die Benutzung von @module-rebuild dauert nämlich sehr lange, weil alle installierten Filepfade überprüft werden. Bei der alternativen Implementation müsste man nur die direkte reverse-Dependency von virtual/linux-sources auswerten, was i.d.R. schneller sein sollte (und zumindest durch das sqlite-Backend beschleunigt werden kann).

----------

## Josef.95

 *mv wrote:*   

> Das ist ein Missverständnis: Mit "schneller implementieren" meinte ich, die bestehende Implementation zu beschleunigen: [....]

 

Argh ja, es war ein Missverständnis meinerseits - ich nahm an das es ums zügige bereitstellen des module-rebuild Sets selbst, im stable portage ging.

Sorry, mein Fehler..

----------

