# globale Anpassungen der Quellcodes durch portage möglich?

## TheSmallOne

Hi,

ich weiß nicht inwiefern das Topic passend gewählt ist, daher versuche ich mal zu erklären, woraum ich eigentlich hinaus will:

Also ich bin so ein bißchen Ordnungsfanatiker, vorallem wenn es um meine Festplatten geht und konkret stört es mich, dass alle möglichen Programme ihre userspezifischen Konfigurationsdateien einfach ins Homeverzeichniss des betreffenden Users schreiben (auch wenn sie "versteckt" sind). Ich hätte gerne, dass alle diese Dateien in einem speziellen Unterverzeichniss ~/etc/ (oder auch ~/.etc/) landen, was m.E. auch wesentlich mehr Sinn machen würde.

Nun ist der Ort, an dem diese Dateien liegen ja in der Regel in den Programmen einkompiliert. Da unter Gentoo das System ja meist sowieso selbst kompiliert wird stellt sich mir nun die Frage, ob Portage irgendwelche Mechanismen bereitstellt, mit dem ich von vornherein sagen kann, dass alle kompilierten Programme ihre userspezifischen Konfigurationsdateien an einem anderen Ort suchen sollen, und sich Portage selbst um die nötigen Anpassungen kümmert.

----------

## STiGMaTa_ch

 *TheSmallOne wrote:*   

> [...]dass alle möglichen Programme ihre userspezifischen Konfigurationsdateien einfach ins Homeverzeichniss des betreffenden Users schreiben (auch wenn sie "versteckt" sind). Ich hätte gerne, dass alle diese Dateien in einem speziellen Unterverzeichniss ~/etc/ (oder auch ~/.etc/) landen, was m.E. auch wesentlich mehr Sinn machen würde.[...]

 

Naja, bei dir daheim mag das vielleicht Sinnlos erscheinen. Aber in Unis und Firmen ist es oftmals so, dass die Home Verzeichnisse von einem entfernten Server via NFS gemountet werden. Wenn der User nun die Dateien in /etc/irgendwas gespeichert hat sind diese nur auf Rechner X verfügbar. Sobald dieser auf Rechner Y einloggt müssten diese dort erneut erstellt werden.

Ausserdem ist es bei einer gewissen Anzahl an Usern üblich /home auf eine eigene Partition zu klatschen. Für Datensicherungen kann man dann z.B. einfach diese Partition dumpen/sichern was auch immer und muss sich bei einem Restore keine Gedanken darüber machen ob man auch alle User Konfigurationen aus /etC/irgendwas gesichert hat etc.

 *TheSmallOne wrote:*   

> stellt sich mir nun die Frage, ob Portage irgendwelche Mechanismen bereitstellt, mit dem ich von vornherein sagen kann, dass alle kompilierten Programme ihre userspezifischen Konfigurationsdateien an einem anderen Ort suchen sollen, und sich Portage selbst um die nötigen Anpassungen kümmert.

 

Naja, prinzipiell ist das schon möglich. Allerdings nur wenn das entsprechende Programm, welches du grad kompilieren willst, dir über configure oder setzen von Variabeln überhaupt die Möglichkeit gibt diesen Pfad zu ändern. Und daran zweile ich schon eher...

Just my 2 Cents.

STiGMaTa

----------

## andix

 *STiGMaTa_ch wrote:*   

> Wenn der User nun die Dateien in /etc/irgendwas gespeichert hat sind diese nur auf Rechner X verfügbar. Sobald dieser auf Rechner Y einloggt müssten diese dort erneut erstellt werden.

 

Er meint ~/.etc also /home/<user>/.etc

Wäre wirklich ein sinnvoller Ansatz das so zu machen. Das Homedirectory wird heutzutage nahezu überflutet von configs, die man nicht immer ohne weiteres als solche erkennt.

Nur wird es kaum möglich sein alle Programme automatisch so umzustellen dass es die configs nach ~/.etc statt ~ ablegt. Man könnte es vielleicht so umgehen indem man $HOME auf /home/<user>/.etc setzt und so die Programme die configs dort ablegen. Macht natürlich wieder Probleme dass auch andre Dateien als configs in ~/.etc kommen...

----------

## Ruad

Dann sollte man halt überlegen, ob man neben $HOME noch soetwas wie $USER-CONFIG einführt. Und ob dann $HOME und $USER-CONFIG gleich sind oder verschieden, dürfte ja jedem wieder selber überlassen sein. Aber dafür müsste man sehr viele Leute davon überzeugen noch eine Variable zu akzeptieren. Oder es bürgert sich ein standard $HOME/.config/ oder was auch immer ein. Viel Vergnügen beim Überzeugen.  :Wink: 

Wobei es auch meinem Ordnungssinn entsprechen würde. An wen muss man sich wenden? Wer hat da ein Wort?

----------

## mrsteven

Du kannst ja auch einfach ein Verzeichnis ~/Dateien erstellen und deine User-Dateien dort speichern.

----------

## TheSmallOne

Es gibt also noch keine Möglchkeit?

 *STiGMaTa_ch wrote:*   

> Naja, prinzipiell ist das schon möglich. Allerdings nur wenn das entsprechende Programm, welches du grad kompilieren willst, dir über configure oder setzen von Variabeln überhaupt die Möglichkeit gibt diesen Pfad zu ändern. Und daran zweile ich schon eher...

 

Diesen Pfad muß man ja nicht unbedingt über Variablen beim configure ändern können. Fakt ist, dass irgendwo beim Kompilieren der Pfad einkompiliert wird. Außerdem hat man bei Gentoo immer auch den Sourcecode. Es sollte also auch über einen Patch möglich sein.

 *Ruad wrote:*   

> Wobei es auch meinem Ordnungssinn entsprechen würde. An wen muss man sich wenden? Wer hat da ein Wort?

 

Man könnte es bei den Leuten vom Filesystem Hierarchy Standard probieren... dann müssten es die Distributoren aber immernoch umsetzen. Ansonsten könnte man die portage-Entwickler fragen, ob sie nicht entsprechende Mechanismen einbauen und vorschreiben könnten, damit Software entsprechend gepatcht/konfiguriert wird.

----------

## _hephaistos_

also das zieht IMHO definitiv grössere kreise! das wird nicht während dem compilen gesetzt (meistens nicht), sondern vom programm selber!

bei kde zB gehts eh relativ einfach, da man den pfad selber setzen kann.

aber es gibt genügend programme (zB c programme), die einfach mit "getenv("HOME")"  oder similar den pfad zur config suchen (und finden)

aber ich versteh das problem eigentlich nicht.

die MEISTEN programme haben ja ihre configs in "~/.<folder|file>" drinnen.

cheers

PS: als beispiel kann man sich den code von zB bash anschauen. is hardcoded im quellcode (static char *bashrc_file = "~/.bashrc" :Wink: 

----------

## TheSmallOne

Der Punkt ist doch aber, dass dieser Pfad nicht spontan aus dem Nichts kommt, sondern irgendwo einkompiliert wird. Und was kompiliert wird kann man auch ändern, indem man den Sourcecode ändert/patcht.

Unter normalen Umständen wäre das eine ziemliche Arbeit das selbst für jedes Programm zu machen und deshlab denke ich, dass hier doch portage eigentlich gut geeignet sein sollte, da es sowieso jedes einzelne Programm kompiliert.

Ein richtiges "Problem" ist es vielleicht nicht, aber es ist eben eine Sache das Ordnungsempfindens... stell' dir doch einfach mal vor Programme würden ihre globalen Konfigurationsdateien einfach in / ablegen, anstatt unter /etc. Wäre das nicht auch ziemlich unschön. Und aus User-Sicht haben wir hier eigentlich genau diese Situation.

----------

## _hephaistos_

 *TheSmallOne wrote:*   

> Der Punkt ist doch aber, dass dieser Pfad nicht spontan aus dem Nichts kommt, sondern irgendwo einkompiliert wird. Und was kompiliert wird kann man auch ändern, indem man den Sourcecode ändert/patcht.
> 
> Unter normalen Umständen wäre das eine ziemliche Arbeit das selbst für jedes Programm zu machen und deshlab denke ich, dass hier doch portage eigentlich gut geeignet sein sollte, da es sowieso jedes einzelne Programm kompiliert.

 

ja das is schon klar!

nur es gibt sicher 50 verschiedene möglichkeiten den pfad zu setzen! wie willst du da vernünftig patchen?

für jedes paket eine if-struktur in portage einbauen?  :Wink: 

zB conky machts so in der art: char configFile[] = "$HOME/.conkyrc";

$HOME wird dann in einer eigenen funktion (substitute_variable oder so ähnlich) durch getenv("HOME") ersetzt.

ausserdem kann man ja nicht davon ausgehen, nur weil etwas "home" heißt in einem programm, dass es der "~" pfad ist! zB konqueror: "home" als home button oder so...

 *Quote:*   

> Ein richtiges "Problem" ist es vielleicht nicht, aber es ist eben eine Sache das Ordnungsempfindens... stell' dir doch einfach mal vor Programme würden ihre globalen Konfigurationsdateien einfach in / ablegen, anstatt unter /etc. Wäre das nicht auch ziemlich unschön. Und aus User-Sicht haben wir hier eigentlich genau diese Situation.

 

nein eben nicht! da config ordner oder files mit "." beginnen.

cheers

----------

## schachti

 *_hephaistos_ wrote:*   

> 
> 
> ja das is schon klar!
> 
> nur es gibt sicher 50 verschiedene möglichkeiten den pfad zu setzen! wie willst du da vernünftig patchen?
> ...

 

Sowas müßte wahrscheinlich in den ebuilds stehen, evtl. ein Patch pro Programm - ziemlich aufwendig.

----------

## TheSmallOne

 *_hephaistos_ wrote:*   

>  *Quote:*   Ein richtiges "Problem" ist es vielleicht nicht, aber es ist eben eine Sache das Ordnungsempfindens... stell' dir doch einfach mal vor Programme würden ihre globalen Konfigurationsdateien einfach in / ablegen, anstatt unter /etc. Wäre das nicht auch ziemlich unschön. Und aus User-Sicht haben wir hier eigentlich genau diese Situation. 
> 
> nein eben nicht! da config ordner oder files mit "." beginnen.

 

Und?

Nur weil sie auf den ersten Blick nicht zu sehen sind ändert das ja nichts daran, dass sie da sind.

Dann ergänze eben bei meiner obigen Aussage, dass die Konfigurationsdateien eben auch Punkte vor ihren Namen haben, wenn sie in / lägen.

 *schachti wrote:*   

> Sowas müßte wahrscheinlich in den ebuilds stehen, evtl. ein Patch pro Programm - ziemlich aufwendig.

 

An etwas derartiges dachte ich.

Aufwändig... ja, für eine einzelne Person. Aber angenommen jemand (der dafür zuständig ist) würde einfach anordnen, dass es eine derartige Option geben muß, und die Umsetzung machen dann die Leute, die für die jeweiligen ebuilds zuständig sind, dann verteilt sich der ungeheure Aufwand auf ungeheuer viele Leute. Außerdem sollte das ganze ja auch erstmal nur einmal nötig sein.

Vermutlich würde es soeine Option auch beim configure geben, wenn die Programmierer erstmal wüssten, dass es da einn Bedarf für gäbe... andererseits sind wir hier 2 oder 3 Leutchen, de das so sehen, ob man das schon Bedarf nennen kann ist so eine Sache.  :Wink: 

----------

## schmutzfinger

Naja das ist in jedem UNIX System so. Ich denke mal das ist in irgendeinem RFC/IEEE so festgelegt. Und das zu ändern geht nicht von jetzt auf gleich. Ich persönlich würde es für total schwachsinnig halten mein System/Homedir derart inkompatibel zu anderen Betriebssystemen/Distris zu machen. Es wäre vielleicht schön das homedir damit übersichtlicher zu machen, aber der Nutzen im Gegensatz zum Aufwand ist nichmal die Überlegung wert. Dann wäre es wohl einfacher deinen liebsten Dateimanager so zu patchen, das er es so aussehen lässt  :Wink: .

----------

## TheSmallOne

 *schmutzfinger wrote:*   

> Ich denke mal das ist in irgendeinem RFC/IEEE so festgelegt.

 

Eigentlich nicht... zumindest nicht, dass ich wüßte.

Soweit ich weiß hat sich diese Verzeichniss-Struktur einfach so entwickelt. Irgendwer hat halt angefangen seine Konfiguration einfach so ins Homeverzeichniss zu schreiben, dann hat es jemand nachgemacht u.s.w.

Am Anfang mag das ja noch überschaubar gewesen sein, als man nur mit einer handvoll Programmen gearbeitet hat und die Konfigurationsateien sowieso noch mit der Hand schrieb, aber heute, wo unzählige Programme ihre Konfigurationen selbstständig beim ersten Start erstellen wäre etwas mehr Ordnung m.E. durchaus angebracht.

 *Quote:*   

> Und das zu ändern geht nicht von jetzt auf gleich.

 

Es muß ja nicht von jetzt auf gleich sein. Aber man sollte zumindest mal damit anfangen.

 *Quote:*   

> Dann wäre es wohl einfacher deinen liebsten Dateimanager so zu patchen, das er es so aussehen lässt .

 

Ich dachte ich hätte bereits deutlich gemacht, dass es mir nicht darum geht, wie es aussieht, sondern darum, wie es ist. Beim Putzen kehre ich ja auch nicht den Schmutz einfach unter einen Teppich, weil es sauber aussieht, sondern ich will das der Schmutz weg ist.  :Smile: 

----------

## Deever

Kurze Zwischenfrage: Was bringt es, das "Durcheinander" in ein anderes Verzeichnis zu verschieben? Dadurch bliebe es ein "Durcheinander", man hätte bei der Verwaltung seiner Daten aber noch ein Verzeichnis mehr zu berücksichtigen, die Komplexität wäre folglich höher als ohne ein solches Verzeichnis.

Gruß,

/dev

----------

## Ruad

man hätte eine strikte trennung von persönlichen, aber automatisch erstellten, und "wirklich" persönlichen,weil von Hand erstellten, Daten. Das kann doch durchaus nützlich sein?! Ich finde den Wunsch zumindest nachvollziehbar.

----------

## STiGMaTa_ch

 *TheSmallOne wrote:*   

>  *schmutzfinger wrote:*   Ich denke mal das ist in irgendeinem RFC/IEEE so festgelegt. 
> 
> Eigentlich nicht... zumindest nicht, dass ich wüßte.
> 
> Soweit ich weiß hat sich diese Verzeichniss-Struktur einfach so entwickelt. Irgendwer hat halt angefangen seine Konfiguration einfach so ins Homeverzeichniss zu schreiben, dann hat es jemand nachgemacht u.s.w.

 

Falsch.

Die Filesystem Hierarchy Standard definiert ganz klar den Sinn und Zweck eines Home Verzeichnisses. Was nicht genau definiert ist, ist der Speicherort für das Homeverzeichnis. Hier gilt /home als Empfehlung.

 *Quote:*   

> Requirements
> 
> User specific configuration files for applications are stored in the user's home directory in a file that starts with the '.' character (a "dot file"). If an application needs to create more than one dot file then they should be placed in a subdirectory with a name starting with a '.' character, (a "dot directory"). In this case the configuration files should not start with the '.' character.
> 
> 

 

 *TheSmallOne wrote:*   

> [..]Konfigurationsateien sowieso noch mit der Hand schrieb, aber heute, wo unzählige Programme ihre Konfigurationen selbstständig beim ersten Start erstellen wäre etwas mehr Ordnung m.E. durchaus angebracht.

 

Ob du es glaubst oder nicht, aber die Tools welche Ihre Configs automatisch in ~/$HOME erstellt haben, taten das auch schon damals!

Ausserdem möchte ich wie schon im vorherigen Post nochmals erwähnen, dass es nicht nur Spielzeugserver gibt, welche bei jemandem daheim herumstehen. Deine Lösung wird besonders dann unpraktikabel, wenn du spezielle Server nur für die Homeverzeichnisse bereitstellst. Deine Lösung würde nur einen mehraufwand bedeuten, welcher einfach nicht nötig ist.

 *TheSmallOne wrote:*   

>  *Quote:*   Und das zu ändern geht nicht von jetzt auf gleich. 
> 
> Es muß ja nicht von jetzt auf gleich sein. Aber man sollte zumindest mal damit anfangen.

 

Nicht "man sollte" sondern "DU" solltest! Wenn du so ein Problem hast mit dem jetzigen System hast und der Meinung bist, dass andere den Vorteil einfach noch nicht eingesehen haben, dann Stelle einen Antrag unter bugs.freestandards.org bezüglich einer FHS anpassung:

 *Quote:*   

> All proposals should be submitted as bugs on bugs.freestandards.org using the "FHS" component).

 

Wobei ich dir jetzt schon versichern kann, dass dein Antrag mit 100% Sicherheit verworfen wird. Sei es nun bei der freestandards group oder bei den Gentoo Entwicklern. Das jetzige System hat sich über Jahrzente bewährt und bloss weil du einen etwas anderen Ordnungssinn hast oder nicht genau den Sinn hinter den Konfigfiles in den Homeverzeichnissen verstehst, wird niemand einen derartigen Aufwand treiben.

Liest sich jetzt zwar etwas hart, aber so ist nun mal die Realität  :Wink: 

Lieber Gruss

STiGMaTa

----------

## STiGMaTa_ch

 *Ruad wrote:*   

> man hätte eine strikte trennung von persönlichen, aber automatisch erstellten, und "wirklich" persönlichen,weil von Hand erstellten, Daten. Das kann doch durchaus nützlich sein?! Ich finde den Wunsch zumindest nachvollziehbar.

 

Mir sei die einfache Frage erlaubt, wo denn nun der Unterschied dabei ist?

Eine Konfigurationsdatei ist - ob nun manuell oder automatisch erstellt - nichts weiter als eine Datei, welche die Konfiguration für ein Programm enthält. Ob du dir nun im Netz für ein Programm Y 100 Optionen zusammensuchst und diese von Hand in ~/.y.rc einträgst oder ob du dich durch ein Menu klickst und etwas änderst spielt doch keine Rolle. Entscheidend ist doch, dass beim nächsten Start nicht alles wieder eingestellt werden muss.

Lieber Gruss

STiGMaTa

----------

## Ruad

Ich kann amaroK z.B. nicht ohne weiteres sagen, wo es die Konfigurationsdateien speichern soll. Wo ich hingegen ein mp3,ogg,pdf,avi,html, usw.usf. speichern will, das ist immer noch mir überlassen. Dort besteht der Unterschied zwischen manuellen und automatischen Dateien. Der smb.conf kann ich ja auch nicht sagen, wo sie zu stehen hat. (soft-/hardlinken beachten wir hier gar nicht erst  :Wink:  ). Insofern finde ich den Vorschlag bzw. die Idee auch weiterhin nicht schlecht. Sichtbarkeit oder Nomenklatur durch den "." hin oder her.

edit: Und da der Computer immer noch dem Menschen dienen soll und nicht umgekehrt, fällt mir doch glatt noch ein Grund für mich ein. Wenn ich von all den Configfiles nur drei bestimmte mir bekannte Programme berücksichtigen möchte und darüber hinaus der Rest den Jordan hinunter darf, und wenn nun ferner in ~ entweder die struktur ~/config und ~/rest/blabulb oder ~/config und ~/restblablub existieren würde, so wäre für mich als Anwender die logische Sicherung einfacher, wenn ich angeben könnte:

sichere ~/config/programm1 ...x und ~/rest

oder

sichere ~, ignoriere ~/config, ausser ~/config/1..x

Und jetzt kommst du und sagst mir, dass ich das ganze über den . auch einfach regeln kann. (ignoriere alle .* bis auf .1 - .x)  :Wink:  aber mir fällt auch noch was besseres ein.Last edited by Ruad on Sun Jan 29, 2006 9:41 pm; edited 1 time in total

----------

## _hephaistos_

 *TheSmallOne wrote:*   

> Nur weil sie auf den ersten Blick nicht zu sehen sind ändert das ja nichts daran, dass sie da sind.
> 
> Dann ergänze eben bei meiner obigen Aussage, dass die Konfigurationsdateien eben auch Punkte vor ihren Namen haben, wenn sie in / lägen.

 

du verstehst mich nicht.

es geht mir hier nicht ums verstecken!

anders ausgedrückt:

es geht darum, dass alle config files eh schon als solche "gekennzeichnet" sind. eben durch den "." am anfang.

würde man da nun ein neues dir "~/etc" einfügen, dann wäre die "kennzeichnung" "etc".

dh: es ist nur eine andere "kennzeichnung" - für dich als anwender sollte es aber keinen unterschied geben, ob der "haufen" nun in ~/.* liegt oder in ~/etc...

> ist das verständlich rübergekommen?

dh: ich versteh den sinn nicht, weil ich eh so auch configs und NICHT configs auseinanderhalten kann - OHNE dem eigenen verzeichnis...

>> eigentlich hat "deever" das ausgesagt, was ich damit sagen will/wollte.

ausserdem is hier sicherlich auch zu beachten: es geht hier um eine unüberschaubar große menge von programmen -> und einen standard, den es zu ändern gilt. sorry, aber das wird wohl nix...

cheers

----------

## TheSmallOne

 *STiGMaTa_ch wrote:*   

>  *TheSmallOne wrote:*   Soweit ich weiß hat sich diese Verzeichniss-Struktur einfach so entwickelt. Irgendwer hat halt angefangen seine Konfiguration einfach so ins Homeverzeichniss zu schreiben, dann hat es jemand nachgemacht u.s.w. 
> 
> Falsch.
> 
> Die Filesystem Hierarchy Standard definiert ganz klar den Sinn und Zweck eines Home Verzeichnisses. Was nicht genau definiert ist, ist der Speicherort für das Homeverzeichnis. Hier gilt /home als Empfehlung.

 

Nur, dass der FHS wesentlich später entstanden ist, als die unixoiden Betriebssysteme. Man hat da also in erster Linie lediglich nur noch den Status quo dokumentiert und an einigen Stellen (wo es Diskrepanzen gab) eine Entscheidung getroffen. Und genau das ist es, was ich unter "hat sich einfach so entwickelt" verstehe. Man hat das nicht so gemacht, weil es einen Standard gab, sondern man hat den Standard hinterher nachgeschrieben.

 *Deever wrote:*   

> Kurze Zwischenfrage: Was bringt es, das "Durcheinander" in ein anderes Verzeichnis zu verschieben? Dadurch bliebe es ein "Durcheinander", man hätte bei der Verwaltung seiner Daten aber noch ein Verzeichnis mehr zu berücksichtigen, die Komplexität wäre folglich höher als ohne ein solches Verzeichnis.

 

Ein "Durcheinander" innerhalb eines Verzeichnisses lässt sich ignorieren (in /etc ist es ja auch ziemlich durcheinander), weil man ja nicht in das Verzeichniss reinwecheln muß. Wenn nun aber das Durcheinander in einem Verzeichniss liegt, in welches man zwingend muß, dann lässt es sich nicht mehr ignorieren. Lagerst du deine alten Besitztümer im Flur (häufiges Vorbeikommen), oder doch eher im Keller und auf dem Dachboden (wo man seltener hinkommt)?

Für einen User ist sein Home-Verzeichniss (m.E.) nunmal sein Flur, sein Asgangspunkt, wo wie / für das System. Und ich bevorzuge eben aufgeräumte Flure.  :Smile: 

Aber ich merk' schon, dass ich irgendwie eher zur Minderheit gehöre, die das so sieht.

----------

## oscarwild

 *TheSmallOne wrote:*   

> Lagerst du deine alten Besitztümer im Flur (häufiges Vorbeikommen), oder doch eher im Keller und auf dem Dachboden (wo man seltener hinkommt)?
> 
> Für einen User ist sein Home-Verzeichniss (m.E.) nunmal sein Flur, sein Asgangspunkt, wo wie / für das System. Und ich bevorzuge eben aufgeräumte Flure. 

 

Keller und Dachboden sind bei unixoiden OS eben als ~/.* gekennzeichnet. Du störst Dich daran, dass man vom Flur aus direkt in den Dachboden kommt, und nicht über einen ~/zugang_zum_dachboden. Alles eine Frage der Sichtweise  :Wink: 

Den großen Vorteil, alle Userconfigs in ~/zugang_zum_dachboden/.* zu packen, sehe ich nicht. Problematisch wäre nur, wenn es üblich wäre, auch "normale" Verzeichnisse mit einem "." beginnen zu lassen - also man nicht mehr unterscheiden könnte, ob es sich um ein Konfigurationsverzeichnis handelt oder nicht.

----------

## TheSmallOne

 *oscarwild wrote:*   

>  *TheSmallOne wrote:*   Lagerst du deine alten Besitztümer im Flur (häufiges Vorbeikommen), oder doch eher im Keller und auf dem Dachboden (wo man seltener hinkommt)?
> 
> Für einen User ist sein Home-Verzeichniss (m.E.) nunmal sein Flur, sein Asgangspunkt, wo wie / für das System. Und ich bevorzuge eben aufgeräumte Flure.  
> 
> Keller und Dachboden sind bei unixoiden OS eben als ~/.* gekennzeichnet. Du störst Dich daran, dass man vom Flur aus direkt in den Dachboden kommt, und nicht über einen ~/zugang_zum_dachboden. Alles eine Frage der Sichtweise 

 

Dann reden wir noch ein bißchen über Sichtweisen: (irgendwie finde ich gefallen daran Metaphern zu erfinden  :Laughing: )

Keller und Dachboden sind eben nicht durch diesen . gekennzeichnet. (Dieser Punkt steht übrigens nicht dafür, dass die Datei eine Konfigurationsdatei ist, sonder dafür, dass sie "versteckt" ist.) Vergleichbar wäre das damit, dass man seine alten Möbel im Flur lagert und sie mit einem Tuch abdeckt um zu signalisieren "Das hier gehört nicht zur Einrichtung".

Was die Objekte auf einem Dachboden kennzeichnet ist aber nicht, dass sie alle gemeinsam abgedeckt sind, sondern, dass sie alle an einem gemeinsamen Platz lagern (nämlich dem Dachboden), der sich eben irgendwo befindet, wo er nicht stört/wo man nicht täglich hinkommt.

Wenn für dich also der Punkt am Anfang einer Datei - der ja lediglich ein Bestandteil des Namens ist - das gleiche ist, wie ein Verzeichniss, legst du dann deine Daten auch alle direkt ins Homeverzeichniss und benennst sie nach dem Muster: "Musikdatei.<name>", "Brief-<name>", "Sonstiges-<name>", "Bilder.Fotos.Urlaub.<name>", oder legst du nicht vielleicht auch Verzeichnisse an um deine Dateien zu ordnen.   :Wink: 

----------

## _hephaistos_

ohne jetzt näher auf deine bemerkung einzugehen! (die vergleiche find ich schon [gut ausgeführt und einleuchtend] nicht sehr passend).

fang einfach mal an:

1) standard ändern (dh: dort sollte schon drinnen stehen, dass nicht "." für configs gilt, sondern ~/etc)

2) programme ändern

   a) patches an die entwickler senden

   b) (was genauso utopisch ist) patches in portage (ebuilds) einbringen

wenn du punkt 1 durchhast, dann helf ich dir bei punkt 2.

aber ich versteh wirklich nicht, wo für dich da das grosse problem ist...

cheers

----------

## oscarwild

 *TheSmallOne wrote:*   

> Dieser Punkt steht übrigens nicht dafür, dass die Datei eine Konfigurationsdatei ist, sonder dafür, dass sie "versteckt" ist.

 

Na wenn da mal nicht Henne und Ei durcheinander kommen!

Unter einem großen konventionellen Betriebsystem gibt es tatsächlich das Dateiattribut "hidden". In der Linux-Welt nicht - es ist lediglich eine Konventionen, Dateien bzw. Verzeichnisse, die mit einem Punkt beginnen, nicht darzustellen. Und wenn ich mal gedanklich mein System durchgehe, fällt mir spontan jedenfalls kein Ordner ein, der aus einem anderen Grund "versteckt" wäre, als um Konfigurationen zu enthalten...

Und wenn wir uns schon über abgedeckte Möbel unterhalten - dann können wir gleich darüber streiten, ob Konfigurationen nicht auf eine eigene Festplatte gehören. Denn Verzeichnisse sind auch nichts anderes als logische "Abdecktücher", die eigentliche Information befindet sich immernoch auf dem selben Datenträger  :Wink: 

----------

## monade

Ich halte den Wunsch auch für absolut nachvollziehbar. Ich hab mich selbst schon oft über dieses Mischmasch aus automatisch erstellen Konfigurationsdateien und allen möglichen persönlichen Daten in $Home geärgert. Mit einem ~/etc/-Verzeichnis hätte man alle Konfigurationsdateien sofort im Überblick. Und dann könnte man sich auch dieses lästige 'ls -a' sparen. (Ganz zu schweigen von den Konqueror & Co-Nutzern, die dafür erst "versteckte Dateien anzeigen" aktivieren müssen)

KDE mach es ja schon so ähnlich, sämtliche *rc-Dateien der verschiedenen KDE-Programme sind in .kde/share/config/ zu finden. 

Allerdings ist es wohl aussichtslos, das ganze über Ebuild-Patches o.ä. für jedes einzelne Programm umzubiegen. Wenn überhaupt würde der Weg über einen wie von STiGMaTa_ch angesprochenen Vorschlag (freestandards.org) gehen können. Am Anfang muss eine neue Empfehlung von FHS (oder welcher Instanz auch immer) stehen. Wären erstmal einige wichtige Projekte von dieser Idee überzeugt, dann würde da der 'Rest' der Linux-Welt vielleicht irgendwann folgen - uns sich ein neuer Standard einbürgern *träum*   :Wink: 

Ich gehe allerdings stark davon aus, dass so eine Idee bei den entsprechenden Instanzen schon diskutiert wurde. Zu naheliegend ist der Vorschlag einfach. Ich werd mal etwas danach googlen..

----------

## _hephaistos_

lösung:

list home etc:

```
alias lshetc="cd ~;ls -d .*"
```

EDIT:

wie wärs mit folgendem, als workaround, bis der standard umgeschrieben wurde:

leg dir eine vernünftige verzeichnisstruktur in deinem ~/ an, damit nur wenige ordner (geschweige denn files) direkt in ~/ liegen.

als zB

~/share

~/docs

~/work

~/u-haft

dann hast du auch eine übersichtliche struktur

ODER ULTIMATE LÖSUNG:

```

cd ~

mkdir etc

mv .* etc

ln -s etc/<every .config file> <every .config file> 

```

cheers

----------

## Qubit

Meine volle Zustimmung!

Ich würde meine persönliche Struktur wesentlich lieber direkt unterhalb $HOME

anlegen, als unter 'work'. Welcher nur exisitiert um den "Config-Dateien" ect.

zu entrinnen!

Also meine Stimme für ~/{etc,.etc,config,.config}

----------

## Genone

a) prinzipiell ist die Idee nicht schlecht

b) allerdings vorerst keine Sache für Distributoren

c) da erstmal eine kritische Masse von Upstream entwicklern da mitziehen müsste

d) denn einfach nur irgendwo einen String ersetzen tuts nicht immer

e) und langfristig massenweise Patches zu pflegen ist nicht praktikabel

f) evtl. mal bei freedesktop.org gucken, da gabs glaub ich mal nen Vorschlag diesbzgl., glaube xfce setzt das auch schon um mit ~/config/xfce (oder so ähnlich)

Zusammengefasst: Idee nicht schlecht, aber fürs erste falscher Adressat.

----------

## McPringle

 *schachti wrote:*   

> Sowas müßte wahrscheinlich in den ebuilds stehen, evtl. ein Patch pro Programm - ziemlich aufwendig.

 

Oder als Patch (Option beim ./configure) beim Autor einreichen. Ist zwar auch aufwendig, aber nur ein mal je Programm nötig und muss nicht gepflegt werden, wenn sich die Programmquellen ändern. Außerdem profitieren da dann auch andere Distris von und man könnte sich die Arbeit quasi "teilen" resp. langsam einführen.

McPringle

----------

