# Wohin mit Distfiles/Kernel/etc.? Gentoo und der FHS

## l3u

Die Diskussion unter https://forums.gentoo.org/viewtopic-p-3891646.html schweift langsam ab ;-) Ich denke mal, hierfür ist ein neues Thema evtl. ganz hilfreich. Oder über Gentoo und den FHS.

 *FHS wrote:*   

> /usr/src : Source code (optional)
> 
> Purpose: Source code may be place placed in this subdirectory, only for reference purposes. Generally, source should not be built within this hierarchy.

 

Wie wäre also der Vorschlag, sowohl die Kernel-Quellen (die ja eh schon hier sind -- aber halt ohne /usr/src/linux-Symlink), als auch die Distfiles nach /usr/src zu legen? Also ohne die Programme auch hier zu bauen!

Im FHS steht aber auch folgendes: ( http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSRCSOURCECODE2 )

 *Quote:*   

> /usr/src : Source code
> 
> The only source code that should be placed in a specific location is the Linux kernel source code. It is located in /usr/src/linux.
> 
> /usr/src/linux may be a symbolic link to a kernel source code tree.

 

Wer hat also Recht?!

Was evtl. auch ganz nett wäre, wäre der ganze Portage-Kram unter /var, also /var/portage/tree /var/portage/distfiles und sowas wie /var/portage/tree_local oder sowas.

 *FHS wrote:*   

> Applications must generally not add directories to the top level of /var. Such directories should only be added if they have some system-wide implication, and in consultation with the FHS mailing list.

 

Würde ja eigentlich okay sein, weil's ja das ganze System betrifft.Last edited by l3u on Wed Feb 07, 2007 2:25 pm; edited 2 times in total

----------

## Bloodsurfer

Ich persönlich halte das so.

Eine eigene Partition unter /usr/portage eingehängt. Dort liegen in Unterordnern der portage tree (/usr/portage/tree), die distfiles (/usr/portage/distfiles), die Kernelsourcen (/usr/portage/kernelsrc), das portage tempdir (/usr/portage/tmp).

So hab ich meine eigentliche Rootpartition frei von derartigen kleinen, sich dauernd ändernden Dateien, alles was nicht unbedingt bei einem Backup mitgesichert werden muss liegt auf der /usr/portage Partition. Mehrere Fliegen mit einer Hand imo.

----------

## slick

Das verschieben des Distfiles-Verzeichnisses steht ja jedem frei. Wofür gibts die Variable DISTDIR sonst?  :Wink: 

```
DISTDIR="/usr/src/distfiles"
```

Allerdings gehen anscheinend einige Scripte (o.ä.) davon aus das sich die distfiles immer in /usr/portage/distfiles befinden, zumindest hatte ich mal kleine Anpassungen vorzunehmen als ich das Verzeichnis verschob. Weiß aber nicht mehr genau was es war. Von daher bevorzuge ich mount -o bind oder einen Symlink wenn ich das Verzeichnis verschieben möchte, statt die make.conf anzupassen.

Ich denke das Gentoo-Team wird sich schon etwas dabei gedacht haben das es in /usr/portage/distfiles ist, man hält sich ja sonst auch sehr gut an das FHS.

----------

## l3u

Also von wegen "sonst hält man sich ja auch gut an den FHS":

Als ich damals einen Bug aufgemacht habe, daß die doch mal das baselayout anpassen sollen, weil Wechseldatenträger unter /mnt nichts verloren haben, sondern unter /media einzuhängen sind und es dieses Verzeichnis gar nicht gibt -- und daß das, was mein Apache liefert nicht unter /var/www gehört, sondern unter /srv (z. B. /srv/www/) und es dieses Verzeichnis ebenfalls nicht gibt -- da bin ich mit Unmut und "wontfix" empfangen worden.

Ich starte mal nen Versuch mit

```
PORTDIR="/var/portage/tree"

PORTDIR_OVERLAY="/var/portage/overlays/local"

DISTDIR="/usr/src/distfiles"

PKGDIR="/usr/binpkg"
```

... was ja irgendwie eher dem FHS entsprechen sollte (das mit /media und /srv hatte ich eh schon immer ;-) Und wenn das Probleme macht, sollte man den Entwicklern jeweils sagen, daß die bitte die Variablen auslesen sollen und nicht die Pfade hard-coden. Mal schauen, wie's läuft :-)

EDIT:

Also den Cache von eix (/var/cache/eix) muß man schonnmal von Hand löschen, damit ein eix-sync wieder geht.

----------

## Klaus Meier

Also ich bin jetzt mal ganz pragmatisch. Bei mir ist alles auf einer Platte. Und da ist es doch total egal, ob da was in /var oder /usr steht. Mein Gentoo hat mit dieser Ordnerstruktur absolut null Probleme. Und ansonsten ändert sich bei meinem Gentoo täglich was. An allen Stellen. Ein emerge --sync verändert /usr/portage, die Distfiles ändern sich dann auch irgendwann mal, täglich werden Dateien in /usr/bin und irgendwelche Bibliotheken geändert. Mal kommen neue Headers, mal ein neuer Kernel.

Also ein Gentoo ist im allgemeinen immer am fließen. Und von daher frage ich mich, ob da solche Diskussionen überhaupt Sinn machen, weil sie nicht von den Gegebenheiten eines Gentoosystems ausgehen. Bei einem Suse oder Fedora mag das anders sein, weil sich da in /usr/bin 6 Monate lang nichts ändert.

Also Verzeichnisse, die es in allen Distributionen gibt, sollten möglichst bei allen an der gleichen Stelle stehen. Aber bei Dingen, die es nur bei Gentoo gibt, da halte ich solche Diskussionen für überflüssig. Irgendwelche Pfade von den Standardvorgaben abzuändern, um dann nur zwei Probleme mehr zu haben, bringt mir nichts.

Also wenn man das ganze auf mehrer Partitionen oder Platten aufteilt, dann machen bestimmte Aufteilungen schon Sinn, im speziellen Fall von Gentoo aber eher nicht. Ich quäle meine erste Gentoopartition seit fast einem Jahr mit allem und habe es auf eine Fragmentierung von 3,5% gebracht. Und Dies scheint ja einer der Hauptgründe zu sein, zwischen relativ beständigen und relativ häufig wechselnden Bereichen zu trennen.

----------

## l3u

Es geht ums Prinzip ;-)

----------

## tgurr

Das Thema Interessiert mich im Prinzip auch. Wo kann man das denn nachlesen, dass die htdocs etc. eigentlich nach /srv/www gehören? Und müssten dann nicht theoretisch auch MySQL Datenbanken nach /srv/mysql o.ä.?

----------

## l3u

Steht alles im Filesystem Hierarchy Standard:

http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM

Bei MySQL ist's denk ich mal Auslegungssache ... sofern die Datenbanken nur von Websites bzw. remote genutzt werden, würd ich schon sagen, daß das nach /srv gehört.

----------

## tgurr

Hmm sehr verwirrend. Apache installiert ja standardmäßig nach /var/www (siehe httpd.spec "%define contentdir /var/www") wenn ich das richtig verstanden habe. Von dem her finde ich es schon ok wie es Gentoo macht. Bei Tomcat allerdings zerpflücken sie aber ja auch die Standard-Pfade, wiso dann nicht auch bei Apache? Kurze Zeit gab es ja mal wieder ein srv-Useflag, ist allerdings auch schnell wieder verschwunden und war per default nicht aktiviert. Wobei ich zugeben muss, dass ich /var/www eigentlich in Ordnung finde.

----------

## l3u

Der FHS gibt ja nur nen Vorschlag an, wie's sein sollte. Was dann jeder einzelne draus macht, bleibt ja sein Bier ;-)

----------

## samsonus

jaja, das liebe problem mit der Standardisierung...  :Wink: 

----------

## l3u

Ich steh auf Standards ;-)

----------

## Necoro

 *Libby wrote:*   

> Ich steh auf Standards 

 

Standards machen Sinn, wenn sie für die Interoperabilität notwendig sind. Wenn sie einfach nur aus Prinzip angewandt werden (wie hier wo es um die Portage-Dateien geht), finde ich sie eher hinderlich  :Wink: 

----------

## Klaus Meier

 *Necoro wrote:*   

>  *Libby wrote:*   Ich steh auf Standards  
> 
> Standards machen Sinn, wenn sie für die Interoperabilität notwendig sind. Wenn sie einfach nur aus Prinzip angewandt werden (wie hier wo es um die Portage-Dateien geht), finde ich sie eher hinderlich 

 

Bingo.

----------

## TheSmallOne

 *Necoro wrote:*   

> Standards machen Sinn, wenn sie für die Interoperabilität notwendig sind. Wenn sie einfach nur aus Prinzip angewandt werden (wie hier wo es um die Portage-Dateien geht), finde ich sie eher hinderlich 

 

Würde ich nicht so sehen.

Ich meine bei Gentoo wird das komplette System selbst kompiliert, da braucht man eigentlich keine Interoperabilität, aber trotzdem geht portage nicht hin und bestimmt für jedes Softwarepaket das Zielverzeichniss per Zufallsgenerator.

Ich finde an Standards sollte man sich gerade aus Prinzip halten.

----------

## Klaus Meier

Sehe ich komplett andersrum. Also eine Datei, die bei Linux auf alles System vorhanden ist, sollte auf allen an der gleichen Stelle stehen. Damit man beim Administrieren eines anderes Systems nicht wieder bei vorne anfängt.

Und was für einem Standard sollen denn /var/tmp/portage oder /usr/portage genügen? Den gibt es doch nur bei Gentoo. Und außerdem, man sollte nichts aus Prinzip machen, warum soll man denn freiwillig das Denken ausschalten?

----------

## Max Steel

Sehe ich wie Klaus,

ICh finde das in /var/ alles reinkommt was irgendwie Temporär íst, ich hab /tmp/ auf /var/tmp1/

und alles was sich nur alle paar updates/installationen verändert in den rest.

----------

## l3u

Du schaltest das Denken nicht aus, sondern du schaltest es eben ein! Weil ich hab mir gedacht: "Okay, den Portage-Baum gibt's nur auf Gentoo-Systemen. Ich kann also nicht schauen, wo ihn andere hin haben. Also _überlege_ ich mir, wo es nach den gängigen Empfehlungen sinnvoll wäre und tu den da hin".

Eben nach /var/portage/tree, /var/portage/overlays und die Distfiles nach /usr/src/distfiles. Ist doch wie bei HTML -- "So lang's der Browser richtig anzeigt, isses doch okay!" -- Willkommen Anno 1995. Mittlerweile hält man sich besser an Standards und es gibt *tada* weniger Probleme.

Ich sehe meine persönliche Freiheit in keinster Weise eingeschränkt, wenn ich den Portage-Baum an die Stelle ins Dateisystem setze, an die er laut FHS-Definition an sich gehören würde. Wem's nicht gefällt, der kann ihn ja auch nach /cooles/verzeichnis/für/portage legen.

Was nach /var kommt ist _nicht_ temporär (siehe FHS), deswegen gibt's ja /tmp und /var/tmp.

Aber nochmal zum Kernel: dessen Quellen gehören ja ohne Frage nach /usr/src. Aber gibt's denn eigentlich die Möglichkeit, die Quellen in /usr/src/linx-<version> zu haben, aber den Kernel dann z. B. in /var/tmp/kernel-<version> zu bauen? Damit eben NICHT der Objektcode in /usr rumliegt? Aber damit eben doch sichergestellt ist, _daß_ der Objektcode noch irgendwo rumliegt, damit nach ner kleinen Änderung make nicht alles nochmal bauen will?

----------

## Genone

Um mal was offizielles dazu zu sagen:

Die Datenverzeichnisse von Portage sind schlichtweg historisch gewachsen, die meisten (insbesondere /usr/portage und Verwandtschaft) wurden vermutlich vor Urzeiten willkürlich von drobbins bestimmt. Vom Prinzip her würden wir die gerne anpassen (nicht nur wegen FHS), allerdings ist das leider nicht ganz so trivial dass wir nur die Standardvariablen in make.globals ändern müssten. Das ist ein ganzer Haufen Arbeit (vor allem organisatorisch) der da dranhängen würde, wodurch das Kosten-Nutzen Verhältnis ziemlich mies wird.

----------

## l3u

Ohne das anzweifeln zu wollen, was du da gesagt hast: was wäre denn der Aufwand?

Wenn man das einfach bei der nächsten Live-CD per default einstellt, dann haben ja schonmal alle neu aufgesetzten Installationen die neue Lokalisation. Und das, was ich gemacht habe, war nur folgendes:

mv /usr/portage/distfiles /usr/src/

mkdir /var/portage; mkdir /var/portage/tree

mv /usr/portage/* /var/portage/tree/

rm -r /usr/portage

mv /usr/portage-overlays /var/portage/overlays

 ln -sf /var/portage/tree/profiles/default-linux/x86/2006.1/desktop/ ./make.profile

rm /var/cache/eix

Dann noch folgendes in die /etc/make.conf

```
PORTDIR="/var/portage/tree"

PORTDIR_OVERLAY="/var/portage/overlays/local"

DISTDIR="/usr/src/distfiles"
```

Und das war's ... was wäre denn da von offizieller Seite noch nötig?

----------

## think4urs11

 *Libby wrote:*   

> Ohne das anzweifeln zu wollen, was du da gesagt hast: was wäre denn der Aufwand?
> 
> ...
> 
> Und das war's ... was wäre denn da von offizieller Seite noch nötig?

 

Wenn es einfach so umgestellt wird trittst du erstmal all denen vor den Kopf die /usr/portage|/usr/portage/distfiles|etc. in einer eigenen Partition zu liegen haben.

Zumindest müßten diese dann ihre /etc/fstab anpassen um wieder 'in line with official setup' zu sein. (oder einen passenden ln setzen, etc.)

Das so ganz nebenbei auch noch sämtliche offiziellen Dokumentationen bzgl. dieser Details geändert werden müssen kommt noch dazu.

Sämtliche dieser Aktivitäten sollten synchronisiert ablaufen da sonst ggf. Doku/Realität nicht mehr zusammenpassen.

usw. usf. etc.

----------

## Genone

 *Libby wrote:*   

> Ohne das anzweifeln zu wollen, was du da gesagt hast: was wäre denn der Aufwand?
> 
> Wenn man das einfach bei der nächsten Live-CD per default einstellt, dann haben ja schonmal alle neu aufgesetzten Installationen die neue Lokalisation. Und das, was ich gemacht habe, war nur folgendes:
> 
> mv /usr/portage/distfiles /usr/src/
> ...

 

Wie schon erwähnt müsste man erstmal auf bereits angepasste Variablen Rücksicht nehmen, wobei dass aber noch trivial ist. Nächstes Problem ist sicherzustellen dass man den ganzen Kram auch verschieben kann (da man ja fürs verschieben eines Verzeichnisses temporär min. den gleichen Platz nochmal freihaben muss), u.U. muss auch der Cache regeneriert werden da an manchen Stellen die Pfade gespeichert werden.

Soviel zu Client Seite, die meiste Arbeit liegt aber woanders, nämlich sicherzustellen dass sämtliche Infra-Resourcen mit der Änderung klarkommen sowie die gesamte Dokumentation anzupassen (eine einfache 1:1 Ersetzung reicht nicht). Dazu kommt noch die Benutzer "Umschulung", sprich die Änderung muss deutlich kommuniziert werden.

Und das alles setzt natürlich vorraus dass man sich erstmal auf eine neue Struktur einigt.

Für einen einzelnen Nutzer der die Änderung bewusst durchführt ist es wie du sagtst kein Problem, wenn man das ganze aber global und automatisiert machen will muss man ein paar Dinge zusätzlich bedenken.

----------

## l3u

Auch wieder wahr ...

----------

## Fauli

 *Libby wrote:*   

> Aber gibt's denn eigentlich die Möglichkeit, die Quellen in /usr/src/linx-<version> zu haben, aber den Kernel dann z. B. in /var/tmp/kernel-<version> zu bauen?

 

Mit der Variable KBUILD_OUTPUT kannst du festlegen, in welchem Verzeichnis der Output des Kernelcompilierens landen soll:

```
export KBUILD_OUTPUT=/var/tmp/kernel-<version>

cd /usr/src/linux-<version>

make
```

Die .config-Datei muss dazu in /var/tmp/kernel-<version> stehen.

Leider gibt es aber Ebuilds, die nicht funktionieren, wenn der Kernel nicht in /usr/src/linux gebaut worden ist. Ich bin mir deshalb nicht sicher, ob das Verwenden von KBUILD_OUTPUT überhaupt offiziell von Gentoo unterstützt wird.

----------

## l3u

Wo kommt die Variable rein? /etc/rc.conf?

----------

## Klaus Meier

 *Libby wrote:*   

> Wo kommt die Variable rein? /etc/rc.conf?

 

/etc/profile

----------

