# Sinnfreie Use-Flag Beschreibungen

## moe

Hi,

eine Sache die mich schon immer aufgeregt hat, muss ich jetzt mal hier loswerden:

Wem nützen sinnfreie Use-Flag Descriptions? Warum werden sie  nich gleich weggelassen, spart n paar Bytes beim Syncen..   :Evil or Very Mad: 

So jetzt wieder sachlich, wollte gerade net-im/gajim emergen:

```
# emerge -pv net-im/gajim

[ebuild    N  ] net-im/gajim-0.10.1  USE="X gnome nls -dbus -libnotify -spell -srv" 0 kB
```

Hmm, was bedeutet des das Flag srv, wird Gajim damit zum Server? Mal nachgucken:

```
# euse -i srv

[-    ] srv (net-im/gajim):

SRV capabilities
```

Aha, danke das hilft mir weiter, aber wenn so lapidar beschrieben ist, muss es ja eine allgemein bekannte Eigenschaft des Programms sein, also such ich mal auf der Seite. Auf Anhieb ist da nichts zu finden, eine Suche im Wiki bringt u.a. SRV DNS-Records. Möglicherweise bedeutet das also das Gajim bei gesetztem Flag SRV DNS-Records unterstützt?

Wenn ja wäre "Adds support for SRV DNS-Records" nicht eine bessere Beschreibung? Wenn nein, was soll es dann bedeuten und wie soll man es bitte herausfinden?

Wenn man sich in /usr/portage/profiles/ die use.desc und insbesondere die use.local.desc anschaut, sieht man dass es kein Einzelfall ist, $foo - enables support for $foo ist da oft vorhanden, teilweise umformuliert aber mit gleichem Sinn.

Ich verlange nicht Erklärungen für jeden Furz, aber dass das Useflag "Pups" Unterstützung für Pups einschaltet is klar, das brauch da nicht stehen.. Mir ist auch klar, dass man in die paar Zeichen die da Platz sind, nicht ne seitenlange Beschreibung mit Abwägung von Vor- und Nachteilen reinbekommt, aber es sollte irgendwie eine Aussage sein, wo man dann wenigstens weiß wonach man suchen soll wenn man die Aussage alleine nicht versteht.

So jetzt gehts mir besser, danke fürs Zuhören  :Wink: 

Gruss Maurice

----------

## Knieper

 *moe wrote:*   

> 
> 
> was soll es dann bedeuten und wie soll man es bitte herausfinden?
> 
> 

 

Ein

```

/usr/portage/net-im/gajim>grep srv gajim-0.10.1.ebuild

IUSE="dbus gnome libnotify nls spell srv"

        srv? ( net-dns/bind-tools )"

```

hilft zumeist grob. Aber ansonsten stimme ich Dir zu.

----------

## STiGMaTa_ch

 *moe wrote:*   

> Wenn nein, was soll es dann bedeuten und wie soll man es bitte herausfinden? 

 

1.) Ich hatte bis zu deinem Post keine Ahnung was Gajim ist.

2.) Ich hatte bis zu deinem Post keine Ahnung was SRV capatibilities sind.

ABER ich habe einfach mal gegoogelt und ein wenig logisch gedacht. Gajim scheint also ein Client für das Jabber Network zu sein. Und anscheinend hat jeder, der Gajim benutzt auch Ahnung wozu man SRV benutzt (denn auf der Homepage von Gajim wird mir null Hinweis darüber gegeben).

Ergo muss SRV nichts Gajim spezifisches sondern etwas Jabber spezifisches sein. Daher also flugs google mit "jabber SRV" gefüttert und schon der erste verfügbare Link erklärt was das ist:

 *Quote:*   

> [...]entsprechende SRV-Records in mein DNS basteln. Diese funktionieren ähnlich wie die MX-Records für Mail, sind aber deutlich flexibler ausgelegt:

 

Als Gegenprüfung den zweiten Link von Cambridge angeklickt:

 *Quote:*   

> 3.2. DNS matters
> 
> In a similar way to emails MX records, Jabber uses the DNS to provide an indirection layer between JIDs and the names of the hosts providing the service. This is based on SRV records, which are effectively a generalized form of MX record that can be used by any protocol. Whereas email only uses MX records for server-to-server connections, Jabber has SRV records for server-to-server and also client-to-server connections; this simplifies client configuration, especially in situations like ours where it is not appropriate to have a server with a hostname of cam.ac.uk.

 

Und somit sollte nun klar sein was es ist. Ist das so schwer??   :Rolling Eyes: 

 *moe wrote:*   

> Wem nützen sinnfreie Use-Flag Descriptions?

 

Niemandem. Aber in diesem Fall ist es keine Sinnfreie Description. Die Use Flag Description soll dir nur Anhaltspunkte geben worum es geht. Wenn DU keine Ahnung hast was SRV capatibilities sind, dann kannst du davon ausgehen, dass DU das im Moment auch nicht benötigts. Und jemand der sich intensiver mit Jabber auseinandergesetzt hat wird zwangsläufig auch schon über SRV gestolpert sein und wissen was das ist.

Aber eben, just my 2 Cents   :Laughing: 

Lieber Gruss

STiGMaTa

----------

## moe

 *STiGMaTa_ch wrote:*   

>  Und anscheinend hat jeder, der Gajim benutzt auch Ahnung wozu man SRV benutzt (denn auf der Homepage von Gajim wird mir null Hinweis darüber gegeben).

 

Soweit war ich auch.

 *Quote:*   

> 
> 
> Ergo muss SRV nichts Gajim spezifisches sondern etwas Jabber spezifisches sein. Daher also flugs google mit "jabber SRV" gefüttert und schon der erste verfügbare Link erklärt was das ist:

 

Auch wenns in diesem Fall stimmt halte ich es im allgemeinen für einen recht gewagten Schluss, schliesslich ist gajim das einzige Programm mit diesem USE-Flag. 

 *Quote:*   

> Und somit sollte nun klar sein was es ist. Ist das so schwer??   

 

Nein, zum selben Schluss bin ich ja auch gekommen, auch wenn ich mir nicht ganz sicher war.

Aber es hätte einfacher sein können, indem die Beschreibung nur ein klitzekleines bisschen eindeutiger ist. SRV-Records

oder sogar SRV DNS-Records hätte mir das Suchen erspart.

 *Quote:*   

> Die Use Flag Description soll dir nur Anhaltspunkte geben worum es geht.

 

Mehr will ich auch nicht, SRV capatibilities mag für einen Jabber-Insider eine geläufige Bezeichnung sein (aber selbst das glaub ich nicht unbedingt, da es kaum Server gibt die SRV-Records verwenden), trotzdem sollte jedem klar sein, dass da eine gewisse Mehrdeutigkeit drinsteckt, die man mit nur einem Wort mehr verhindern kann. 

 *Quote:*   

> Wenn DU keine Ahnung hast was SRV capatibilities sind, dann kannst du davon ausgehen, dass DU das im Moment auch nicht benötigts.

 

Hmm, würd ich im Allgemeinen auch nicht unterschreiben wollen. Wenn ich z.B. in KDE meinen USB-Stick autogemountet haben möchte, weiß ich noch lange nicht was hal ist, würde also demnach nicht aktivieren. Das nur als Beispiel, die Description von hal gibt allerdings genug Anhaltspunkte um zu googlen..

 *Quote:*   

> Und jemand der sich intensiver mit Jabber auseinandergesetzt hat wird zwangsläufig auch schon über SRV gestolpert sein und wissen was das ist.

 

1. Siehe oben

2. Ich wollte keinen Jabber-Server installieren, lediglich einen Client. Und ich glaube nicht dass man sich dafür intensiver mit Jabber auseinandersetzen muss.

Im Grossen und Ganzen wollt ich jetzt auch nicht speziell dieses USE-Flag diskutieren, sondern allgemeine sinnfreie Beschreibungen. Klar kann man alles irgendwie durch googlen herausfinden, aber bei einer textbasierten Installation z.B. ist das eher umständlich. Also wenns vermeidbar ist, sollte es doch nicht zu schwer sein eindeutigere Beschreibungen zu wählen.

Gruss Maurice

----------

## think4urs11

Das Problem ist leider das gleiche wie an so vielen Ecken...

Es gibt einfach zuviel Arbeit für zuwenig aktive contributors. Klar wäre es vom logischen Standpunkt aus betrachtet das einfachste eine sinnvolle Beschreibung der USE-Flags dort einzufordern wo sie entstehen - also bei den Devs.

Nur haben die jetzt bereits oft 'Land unter' was man so zwischen den Zeilen herauslesen kann.

Noch dazu sind Devs nicht unbedingt auch die richtigen um Sachverhalte allgemeinverständlich (ich will nicht sagen dau-sicher) in Worte zu fassen.

Noch dazu ist die genaue Funktion der Flags ja paketspezifisch immer etwas anderes (im Detail), d.h. es müßte auch paketspezifisch gepflegt werden.

Ein Ansatz wäre vielleicht die ebuild-Specs dahingehend aufzubohren um diese Beschreibungen mitzuführen und für den Fall das keine spezifische Beschreibung vorliegt eine allgemeine auszuspucken. Aber alles steht und fällt mit geeigneten Ressourcen die sich darum kümmern.

----------

## l3u

Das wär meiner Meinung nach das beste. Wenn ein USE-Flag allgemein benutzt wird (wie z. B. "kde" oder "vorbis" oder sowas), dann kann man die allgemein beschreiben. Wenn's aber in spezieller ist, sollte die Erklärung dafür im ebuild selbst stehen ...

----------

## Klaus Meier

Also ich würde es sehr begrüßen, wenn es irgendwo mal ein Erklärung für alle USE-Flags gäbe. Ich nehme ja schon Ufed, da werden einige ja recht gut erklärt. Aber andere, da steht dann beim Flag xyz: Dieses Flag bewirkt, das xyz aktiviert wird. Und dafür kann ich mir absolut null kaufen, weil ich hinterher genauso viel weiß wie vorher. Vielleicht mal auf dem Wiki, einen neunen Eintrag USE-Flags? Oder hier unter den Docs bei www.gentoo.org? Wenn da alle mitmachen, dann haben wir die doch bestimmt bald erklärt.

----------

## moe

Wie wird denn das überhaupt momentan gehandhabt? Es gibt ja in /usr/portage/profiles die use.desc für allgemeingültige Beschreibungen, und use.local.desc für paketspezifische. Aber wie kommen die Beschreibungen darein? Angenommen ich erstelle ein neues ebuild und führe ein neues USE-Flag ein, gibts einen Maintainer für diese beiden Dateien, oder werden die automatisch (anhand was?) erstellt?

Und wenn ich nun der Meinung bin ich habe eine bessere Erklärung für ein bestimmtes USE-Flag was sollte ich tun, einen Bug beim betreffenden Paket ist ja a) umständlich und b) auch nich möglich bei allgemeingültigen Flags.. Kennt sich da jemand mit der tieferen Materie aus?

Gruss Maurice

P.S. Vielleicht wär ja auch eine community-gepflegte Seite für USE-Flags und was sie speziell bei Paket Y bewirken sinnvoll. Z.B. oben erwähntes KDE Flag, klar bedeutet es Unterstützung für KDE, aber was bewirkt es z.B. bei openoffice genau? Oder gnome, bei manchen Paketen bedeutet das disablen von diesem Flag ja auch dass das Paket dann gar keine GUI hat, was ja auch nicht immer im Sinn von dem KDE-Nutzer ist der gnome normalerweise disabled hat.

Wie siehts aus, eine sinnvolle etwaige Erweiterung fürs Wiki oder gentoo-portage.com, oder zu grosser Aufwand?

----------

## Klaus Meier

Da hast du meinen Beitrag noch mal um einen wichtigen Punkt erweitert. Das es nicht nur darum geht, was ein Flag allgemein bedeutet, sondern was es im Paket bewirkt. Was KDE, Gnome, gtk und qt global bedeuten, dürfte allgemein klar sein. Aber wenn ich Openoffice z.B. mit oder ohne gstreamer kompiliere, was ich zur Zeit gerade tue, dann ist mir das nicht klar, was das bewirkt, auch wenn mir sonst klar, was gstreamer ist.

Also irgendwie sind das zwei Dinge. Zum einen eine allgemeine Beschreibung, was das Flag bewirkt. Und dann eventuell eine Erweiterung der Ebuilds, wo der Einfluß des Flags auf das Paket im Speziellen beschrieben wird.

Wenn ich so an die Zahl der USE-Flags denke, dann kann ich mir vorstellen, daß ein Anfänger davon erst mal abgeschreckt wird. Bei mir hat es auch etwas gedauert, bis ich damit warm geworden bin. Und da hatten wir vielleicht 80% weniger.

----------

## moe

Sorry hab deinen ersten Beitrag dazu auch erst jetzt gelesen, hab wohl 10 Minuten lang an meinem geschrieben.

Wenn das noch mehr als wir beide für ne sinnvolle Idee halten, kann man sich ja anfangen sich Gedanken um ne Umsetzung zu machen.

Gruss Maurice

----------

## Klaus Meier

Punkt eins: USE-Flags im allgemeinen. www.gentoo.org wird im Bereich Dokumentation um ein Wiki zu USE-Flags erweitert. Halte ich für die einfachste Lösung.

Punkt zwei: USE-Flags im speziellen. Wenn man das zu jedem Paket in die Ebuilds einbaut, da gab es doch bei Geneticone (sorry, heißt ja jetzt anders) eine Funktion, daß zu jedem USE-Flag die allgemeine Beschreibung angezeigt wird. Da sollte sich dann aber der für dieses Ebuild verantwortliche die Texte schreiben.

----------

## think4urs11

 *Klaus Meier wrote:*   

> Da sollte sich dann aber der für dieses Ebuild verantwortliche die Texte schreiben.

 

Oder wie gesagt wahlweise diese optionale Info aus einer zusätzlichen Quelle (extra Datei im Portagebaum pro Package) herangezogen werden, dann könnte die Pflege auch von non-Devs/Frewilligen vorgenommen werden und die Devs davon entlasten.

----------

## schmutzfinger

Ich bin mal so frei zu behaupten das die devs oft auch nicht wissen was ein USE-Flag im Detail bewirkt. Weil es zum Bauen den ebuilds ziemliche egal ist. Man guckt sich ./configure --help an und wenn es da --enable-kde gibt, dann nutzt man die kde eclass und fertig. Allgemein kann man immer ins ebuild gucken und dort nach "flag?" suchen, dann sieht man was es für Abhängigkeiten auslöst und welche configure Optionen es setzt. Alles weitere ist Sache der devs vom entsprechenden Projekt, dort ist meist auch nicht im Detail beschrieben welche configure Option was macht. Die Flag-Beschreibungen sind genauso aussagekräftig wie ./configure --help und ich kann sehr gut verstehen, dass es einem gentoo dev ziemlich egal ist was da genau passiert. Für ihn geht es primär darum das Paket für gentoo zur Verfügung zu stellen. Er wird also die configure Optionen in Flags übersetzen und das ebuild mit allen möglichen Flag Kombinationen testen.

Das ist jetzt ein wenig überspitzt ausgedrückt und trifft mit Sicherheit nicht auf jedes Paket zu. Aber es kann ja nicht auch noch Aufgabe der Distri sein, die Software zu dokumentieren.

----------

## musv

Also meine bisherigen "Tests" oder eher unfreiwillige Versuche waren:

Hab einmal sim mit KDE-Unterstützung und einmal ohne compiliert. Der Unterschied bestand dann darin, daß mit KDE-Unterstützung:

- in der Hilfe-Ecke das "About KDE" drinstand

- die Config-/Userprofil-Dateien in ~/.kde/share/apps/sim abgelegt waren. 

Ohne KDE-Unterstützung befanden sich diese Dateien in ~/.sim

Jetzt hab ich auch mal das gnome-USE-Flag aus meinen System verbannt. Da wollte z.B. gqview neu compiliert werden. Und da hab ich wiederum (bisher) überhaupt keinen Unterschied feststellen können zwischen +gnome und -gnome.

Wäre mal ganz hilfreich zu wissen, was die USE-Flags speziell auslösen. "Adds Gnome Support" sagt da ja auch nicht soviel aus. Zumindest eine speziellere Beschreibung der allgemeinen USE-Flags wären mal gutes Projekt für ein Wiki. Ist auch klar, daß das nicht (alleinige) Aufgabe der Devs sein kann.

Und dann hätte ich noch einen Vorschlag: 

Ufed und Profuse sind 'ne feine Sache. Allerdings wird man von der Fülle der USE-Flags darin förmlich überschlagen. Nicht ganz vorteilhaft dabei ist, daß die globalen und die lokalen USE-Flags einfach so durcheinander (alphabetisch geordnet) in der Liste auftauchen. Ich würde eine Trennung zwischen lokalen und globalen Flags in ufed und profuse als vorteilhaft ansehen - also nach Art von Alsamixer, wo man mit Tab zwischen Aufnahme, Wiedergabe und allen Reglern umschalten kann.

STiGMaTa_ch:

Das ist zwar schön und gut, daß man mit Google und etwas Sucherei die Bedeutung der USE-Flags / Configure-Parameter herausbekommen kann. Aber ich hab mich teilweise bei manchen USE-Flags schon Stunden durch irgendwelche verwinkelten Seiten und Foren des Internets gewühlt, um irgendwelche Schnipsel von Infos für die entsprechende Bedeutung zu finden. Wenn jetzt ein Programm (z.B. Apache) ein paar mehr USE-Flags besitzt, dann kann dafür schon schnell mal ein Tag draufgehen, bis man die Bedeutung der meisten USE-Flags durch mühsames Googlen und zig Unterverweisen herausgefunden hat.

----------

## STiGMaTa_ch

 *musv wrote:*   

> STiGMaTa_ch:
> 
> Das ist zwar schön und gut, daß man mit Google und etwas Sucherei die Bedeutung der USE-Flags / Configure-Parameter herausbekommen kann. Aber ich hab mich teilweise bei manchen USE-Flags schon Stunden durch irgendwelche verwinkelten Seiten und Foren des Internets gewühlt, um irgendwelche Schnipsel von Infos für die entsprechende Bedeutung zu finden. Wenn jetzt ein Programm (z.B. Apache) ein paar mehr USE-Flags besitzt, dann kann dafür schon schnell mal ein Tag draufgehen, bis man die Bedeutung der meisten USE-Flags durch mühsames Googlen und zig Unterverweisen herausgefunden hat.

 

Ich sage es nochmal. Wenn du keine Ahnung hast was das USE Flag bewirkt, dann brauchst du es auch nicht. Prinzipiell willst du doch das Programm X installieren und nicht das USE Flag!

Oder geht Ihr Leute wirklich hin und sagt: "Oh, Apache hat LDAP Unterstützung. Hmm.. mal schauen was die USE Flag description sagt. Ah "Adds LDAP support (Lightweight Directory Access Protocol)" Cool, jetzt weiss ich - ein wenig - was es ist und installiere LDAP Unterstützung." ???

Das kann doch nicht sein? Macht Ihr das im normalen Leben auch? Schaut Ihr z.B. beim Autokauf zuerst alle Features und Optionen an und entscheidet euch dann anhand derer was ihr kauft? Also ich setze mich vorhin hin, entscheide was mir an meinem Auto wichtig ist (z.B. Maximalpreis, Benzin/Diesel, Verbrauch etc.) und kaufe dann das Auto, welches meiner Vorstellung am nächsten kommt. Wenn ich nun ein Auto mit und eines ohne ESP habe, dann wird nicht ESP der Ausschlaggebende Grund für den kauf sein, sondern ob das Auto meinen Bedürfnissen entspricht.

Meiner Meinung nach sollte das mit Software genau so geschehen. 

Für jemanden der weiss was "Lightweight Directory Access Protocol (LDAP)" ist, der kann sich unter der oben genannten Beschriebung vorstellen was das ist. Wer das nicht kennt, braucht mehr Infos. Und die muss er sich eben besorgen. Denn nur weil jemand die USE Flag ldap unter apache setzt hat er deswegen noch keinen funktionierenden LDAP Server. Er fügt dem Apache mit der Flag ja nur "die Möglichkeit es zu nutzen" hinzu.

Das aufsetzen und nutzen von LDAP bedeutet nun wiederum, dass man sich erst in eine menge Dokus einlesen muss bevor man das ganze sinnvoll nutzen kann. Aber eigentlich wolltet Ihr doch nur schnell apache installieren und nicht 2 Tage mit einlesen und LDAP verbraten oder??

Und genau das ist es was ich mit "Wer nicht weiss was die USE Flag bedeutet, braucht diese auch nicht" meine!

Just my 2 Cents

Lieber Gruss

STiGMaTa

----------

## Knieper

 *STiGMaTa_ch wrote:*   

> Ich sage es nochmal. Wenn du keine Ahnung hast was das USE Flag bewirkt, dann brauchst du es auch nicht.

 

Oh, dann muesste die Anfaenger-make.defaults ja leer sein.

 *Quote:*   

> Oder geht Ihr Leute wirklich hin und sagt: "Oh, Apache hat LDAP Unterstützung. Hmm.. mal schauen was die USE Flag description sagt. Ah "Adds LDAP support (Lightweight Directory Access Protocol)" Cool, jetzt weiss ich - ein wenig - was es ist und installiere LDAP Unterstützung." ???

 

Steht ldap nicht inzwischen auch in der make.defaults?

 *Quote:*   

> Das kann doch nicht sein? Macht Ihr das im normalen Leben auch?

 

Um Deiner Autoanalogie zu folgen - ja. Wenn ich keinen Anhaenger brauche, dann nehme ich ihn nicht mit. Ich brauche auch die Rundumleuchte, den Kindersitz und den Dachtraeger nicht. Dafuer haette ich gern ein Reserverad. Ich denke die meisten hier nutzen Gentoo, weil sie ihr System individuell aufsetzen moechten und auch Interesse daran haben, zu wissen, wie etwas funktioniert.

 *Quote:*   

> Und genau das ist es was ich mit "Wer nicht weiss was die USE Flag bedeutet, braucht diese auch nicht" meine!

 

Aber vlt. gibt es ja Funktionen, die man nicht kennt, aber sich trotzdem mal anschauen will.

Ich denke, man sollte den Leuten eher sagen, wo sie mehr Infos finden, anstatt sie mit "kennste nich - brauchste nich" abzuspeisen.

Kleines Bsp.: X ist per default gesetzt. Alles schoen und gut, bis man mal ohne X versucht zB. elinks zu starten. Ging nicht - und das bei einem Konsolenprogramm! Schiet auf die X-Funktionalitaeten. Aber bevor ich mich weiter ueber die Default-Flags aufrege, hoer ich mal lieber auf.   :Wink: 

----------

## franzf

 *STiGMaTa_ch wrote:*   

> Das kann doch nicht sein? Macht Ihr das im normalen Leben auch? Schaut Ihr z.B. beim Autokauf zuerst alle Features und Optionen an und entscheidet euch dann anhand derer was ihr kauft? Also ich setze mich vorhin hin, entscheide was mir an meinem Auto wichtig ist (z.B. Maximalpreis, Benzin/Diesel, Verbrauch etc.) und kaufe dann das Auto, welches meiner Vorstellung am nächsten kommt. Wenn ich nun ein Auto mit und eines ohne ESP habe, dann wird nicht ESP der Ausschlaggebende Grund für den kauf sein, sondern ob das Auto meinen Bedürfnissen entspricht.

 

Nettes Beispiel, nur hat es einen Haken:

Du kannst erst entscheiden (auch vorher), ob du z.B. ESP, ABS, ... brauchst, wenn du weißt was das zu bedeuten hat!

Und dafür muss man sich informieren. Nun stell dir vor, Du frägst deinen Händler, was ABS in der Liste bedeutet, und der sagt dir: "Das heißt, dass das Auto ABS hat", dann haust du dem doch die Beschreibung um die Ohren, oder? Aber bei solchen Sachen findet man meist einen kompetenten Menschen in seinem Bekanntenkreis, oder man kommt gut mit Google klar, dann kann man sich über diese Bedeutung informieren.

Da man alltäglich mit Autos und deren ABS zu tun hat, aber recht selten unbedingt einen Apache mit LDAP braucht, liegt die Hürde beim Auto schon etwas niedriger.

Ich bin da auch für ein bisschen mehr Gesprächigkeit von Portage, wenn es um die Bedeutung eines Use-Flags geht, aber nur da wo man aus dem USE-Flag nicht sofort auf etwaige Abhängigkeiten mit eindeutiger Funktion schließen kann (ldap beim Apache dürfte klar sein: ldap -> openldap -> webseite -> fertig).

Grüße

Franz

----------

## Hypfvieh

Im großen und ganzen schließe ich mich moe an. 

Ich meine, wenn jemand die Beschreibungen net braucht, dann muss er sie auch net lesen. Wenn man aber über das ein oder andere kryptische USE-Flag stolpert, sollte man doch zumindest ne sinnige Erklärung kriegen.

Die Frage ist halt wie man sowas umsetzt. Ich meine, wenn dann solls ja für alle sein und nicht nur für nen Teil der Leute. 

Da ist jetzt die Frage, kann man sowas "mal eben" in portage integrieren (für stigmata gibts dann den portage USE-Flag "nouselessdescriptions")?

Wenn ja, dann finden sich hier denke ich mal genug Freiwillige (mich eingeschlossen) die gern mal ein wenig was zum USE-Flag-wusel auflösen beitragen würden. 

Falls das nicht so ohne weiteres geht, ist die Frage ob mans ins Wiki übernimmt oder eine Unterseite erstellt auf der man sowas ein und Nachtragen kann. Wobei da der Nachteil ist, das wenn jeder reinschreiben darf, wahrscheinlich auch Unfug angestellt wird. Wenn aber nur ne Hand voll Leute das administrieren, die Arbeit zuviel wird. Ebenfalls sollte man bedenken, das einem so ne Liste nichts bringt, solang man noch mitten in der Installation von Gentoo steckt. Da wäre was lokales, formloses besser geeignet.

Als dritte Möglichkeit sehe ich da noch die Beschreibungen als "Einzelpaket" zu liefern. Sprich ein Paket das emerged werden muss und die Beschreibungen enthält inklusive passendem Konsolenbefehl zum suchen.

----------

## Klaus Meier

Die Angst, daß bei einem Wiki Müll reingeschrieben wird, gab es schon immer. Aber die Praxis hat gezeigt, daß dies nur zu einem ganz kleinen Teil der Fall ist. Und da man die Schreibrechte ja mit der Anmeldung in diesem Forum koppeln kann, sehe ich da kein Problem. Aber wo stehen eigentlich die ganzen USE-Flags? Ufed zeigt mir viel mehr an, als in der use.desc drin stehen. Irgendwo muß ufed die doch herbekommen, mitsamt der zu kurzen Beschreibung?

----------

## Necoro

 *Klaus Meier wrote:*   

> Aber wo stehen eigentlich die ganzen USE-Flags? Ufed zeigt mir viel mehr an, als in der use.desc drin stehen. Irgendwo muß ufed die doch herbekommen, mitsamt der zu kurzen Beschreibung?

 

use.local.desc  :Smile:  ... da stehen die paketspezifischen

----------

## moe

Zu dem "wenn man nich weiß was es ist, brauch mans auch nicht", hatte ich in meiner ersten Antwort schon was gesagt.

Und auf Autobeispiele steh ich auch  :Wink: 

Bsp. 1 Ich steh im Autohaus und frage den Verkäufer was "ZV m. FB" bedeutet und der antwortet: "Das heißt das Auto hat ZV m. FB" Ich würd mich umdrehen und in ein anderes Autohaus gehen.

Bsp. 2 Ich habe mir vorher Gedanken gemacht, und möchte ein besonders günstiges Auto kaufen (und noch diverse andere Vorstellungen). Das Autohaus "emerge minus peh-vau" bietet mir cars-honda/civic mit dem Flag "hybrid" an. Kenn ich nicht, brauch ich also nicht.

Bsp. 3 Ich hab die Kohle satt, und probiere ständig neue Autos aus, da hab ich natürlich keine Lust mich mit jedem einzelnen genauer auseinanderzusetzen. Aufgrund dieser Unwissenheit, hab ich beim letzten Probieren bei cars-porsche/cayenne z.B. "servo", "leder" und "el. FB" nich gesetzt. Ich hab dann beim nächsten Stammtisch meinen Kumpels gesagt, dass sie sich auf keinen Fall son Auto kaufen sollen. Da gehen noch nichmal die Fenster alleine auf.

Aber eigentlich waren wir schon bei nem anderen Thema, es muss ja nicht jeder meiner Meinung sein, aber da es doch einige gibt würd ich eigentlich lieber dadrüber diskutieren:

Ich würd das lieber auf einer Art wiki-Basis machen, zumindestens so anfangen, eine Integration in Portage kann man dann glaub ich auch besser diskutieren. So könnten die Use-Flag Beschreibungen auch länger sein, und eine kürzere möglicherweise besser Kurzbeschreibung kann ja dann später (wenns genug Leute gesehen und evtl berichtigt/verbessert haben) in die use.[local.]desc einfliessen.

Interessanter find ich allerdings die Auswirkungen einzelner USE-Flags auf einzelne Pakete. Und da würde sich meiner Meinung nach eine Erweiterung bestehender Systeme, die schon Paketinformationen listen, anbieten. Wie eben gentoo-portage.com oder packages.gentoo.org, gibts eigentlich noch andere?

Gruss Maurice

----------

