Hallo *,
On Fri, Apr 08, 2005 at 02:49:46PM +0200, Rene Engelhard wrote:
> Am Donnerstag, 7. April 2005 12:38 schrieb Christian Lohmaier:
> > erstens habe ich mich nicht gegen den Workaround gestellt, sondern gegen
> > die Begründung und die Aufmachung des Issues. Deine Vorwürfe sind
> > schlichtweg falsch gewesen.
>
> Warum hast Du dann nicht (als Verantwortlicher für den Patch, der das
> verursacht hat) das nicht direkt selbst gefixt?
Wie denn? Ich glaube Du hast meinen Standpunkt immer noch nicht
verstanden.
Das Specfile war und ist fehlerfrei. Daß es das in rpm konfigurierte
Verzeichnis verwenden will ist kein Bug.
Daß dieses Verzeichnis in der Standard-konfiguration von RPM in
/usr/irgendwas liegt und man deswegen (und *nur* deswegen) root rechte
braucht ist zwar nicht schön, hat aber erstmal nix mit dem spec-file zu
tun.
Das ist eine Konfigurationsfrage.
Ich habe also nix veruracht. Die Ursache ist eine IMHO unsinnige
Default-Konfiguration von RPM.
Und wie hätte ich das selbst fixen sollen ohne CVS-Schreibrechte, ohne
CWS?
Wiegesagt gibt es zwei möglichkeiten das Problem zu lösen:
* RPM entsprechend konfigurieren
-> Da kann ich überhaupt nix machen, ich kann schließlich nicht auf
Deinem Rechner rumpfuschen
Das kann entweder der debian-maintainer des RPM-Pakets, das mir
immer noch nicht ganz klare "autobuild"-system oder eben der
einzelne Nutzer.
* das Konfigurationsverzeichnis mittels Kommandozeilenparameter
überschreiben
-> Da hab ich auch gleich geschrieben wo man was hinschreiben muß
,----
| "[...] pass --define "_builddir some/unxlngidir" to rpm (as already the
| case with _rpmdir)"
`----
Wie also hätte ich das Deiner Meinung nach fixen sollen?
> > zweitens habe ich selbst keine cvs-Schreibrechte geschweige denn einen
> > CWS (kann den fix also gar nich selbst einbauen)
>
> aber Du haettst den patch machen koennen.so schwer war der dann auch nicht..
> Ich haette den dann liebend gerne committet oder obr haette das tun koennen.
Ich nahm an daß obiges so verständlich genug war (wie Du selbst
schreibst: So schwer war der dann auch nicht). Das nächste Mal
schreib ich eben den Patch.
> > drittens hast Du vermutlich gleich Dein heiliges Debian angegriffen
> > gefühlt (und auch rpm selbst als kaputt bezeichnet) als ich schrieb daß
>
> Hast Du auch.
Nein, Du hast das gleich ins Spiel gebracht ohne daß ich ein einziges
Wort über Debian verloren habe.
Ich schrieb:
,----
| It is a brain-damaged default of RPM to have the build dir below /usr
| and not below the users home, but this is not a bug in the specfile.
`----
Kein Wort über debian sondern über RPM selbst. Aber Du beziehst das
gleich auf Dein debian und schreibst:
,----
| And no, I don't consider Debian's rpm env broken, sorry.
`----
> > es wegen einem "brain damaged default of RPM" (der
> > Konfiguration von RPM, nicht nur bei debian) zu dem Problem kommt.
>
> Nein, habe ich nicht.
Doch, Du hast das gleich auf Debian bezogen. So in der Art: "Die
Konfiguration bei Debain kann gar nicht verkerhrt sein" (siehe oben)
Ich schrieb nur: Wenn es bei einem System nicht erlaubt ist rpm so zu
konfigurieren daß es funktioniert, dann ist das ein Fehler im jeweiligen
System, nicht im Specfile.
> RPM hat wie Du schon richtig gesagt hast einen kaputten
> default. Das die Rechte da nicht simmen und so ist eindeutig. Aber das ist
> kein Grund, zu sagen, bitte fixt die permissions oder setzt was in ~/.rpmrc,
> weil das ein manchen situationen einfach gar nicht geht.
Hättest Du gleich von Anfang an geschrieben daß es sich um so eine
Situation geht..
Ich kenne aber immer noch keine Situation in der sowas nicht gehen soll.
Wenn die autobuilder nur das installieren was gebraucht wird, dann soll
der autobuilder das was installiert wird auch entsprechend einrichten
das es funktioniert. Für alles mögliche gibt es dpkg-reconfigure (oder
so ähnlich) - warum sollte ein Autobuilder oder ein anderes
automatisierte System es nicht fertigbringen die installierten Tools
entsprechend zu konfigurieren?
Wenn das sowieso immer ein extra nutzer ist kann auch das RPM-Paket eine
enstprechendes Konfigurationsfile für diesen Nutzer installieren.
Um es mal ganz klar zu sagen:
Wenn der Autobuilder als user laufen soll und es nicht erlaubt ist dem
Autobuilder ins Handwerk zu pfuschen (indem man selber konfiguriert),
dann ist der Autobuilder nicht tauglich um RPM-Pakete zu erstellen. Wenn
er RPM installiert sollte er es auch entsprechend konfigurieren. (bzw.
das RPM-paket selbst sollte eine andere Standardkonfiguration haben).
Der Autobuilder ist dann nicht inder Lage irgendein beliebiges reguläres
RPM-Paket zu /bauen/ [1] und nicht nur zu packen (epm & die anderen
Menü-Pakete packen nur, bauen aber nix)
Wenn Du eine solche Situation als "tauglich konfiguriert" verstehst,
dann soll es mir auch Recht sein.
[1] Ohne Hacks, ohne die Konfiguration jedesmal per Kommandozeile zu
überschreiben
> Die ganzen menues und so werden mit rpm gebaut und es ist nicht erlaubt,
> etwas
> an dotfiles waehrend des build zu veraendern.
Das macht man auch vorher, ein einziges Mal und man hat ruhe.
Deine MTA konfigurierst Du auch, Deine locale configurierst Du auch,
etc.
Für alles Mögliche gibt es dpkg-reconfigure oder wie das heißt. Nur bei
rpm soll das nicht möglich sein?
> [...]
> > viertens habe ich gleich in meinem ersten Kommentar die entsprechenden
> > Workarounds/Lösungen genannt.
>
> Hast Du. aber trotzdem andere Patches gemacht.
? Bitte zeige mir doch den "anderen Patch" (oder gleich mehrere) den/die
ich angeblich gemacht habe.
> > fünftens bist Du sehr schnell beleidigend geworden.
> >
> > http://qa.openoffice.org/issues/show_bug.cgi?id=44853
>
> Ausser dem "braindamaged" im titel sehe ich das nicht.
Tja, scheint so. (Im titel steht übrigens "insane")
> Wenn Leute, die einen
> Bug eingebaut haben, sich weigern selber einen patch zu schicken, naja...
Nochmal: Der "Bug" ist die Default-Konfiguration von RPM. Das was jetzt
eingebaut ist ist (wenn man Dein Problem zu Grunde legt und nicht eine
Policy daß alles interhalb von einem unxlngi* Verzeichnis liegen soll)
ein Hack der das Problem nur umgeht.
>> [http://www.openoffice.org/issues/show_bug.cgi?id=46018]
>
> > daß bei --enable-symbols darauf hingewiesen wird daß sie durch
> > --enable-crashdump aktiviert wird.
>
> Das habe ich gemacht.
Nicht beim ersten mal.
> > | * configure --help should report that "--enable-crashdump" defaults to
> > | STATIC * configure --help should report that "--enable-symbols" is
> > | activated by default because of --enable-crashdump is enabled by default
>
> Habe ich im ersten commit direkt gemacht.
Nein. Weder hast Du das default (STATIC) reingeschrieben, noch hast Du
bei --enable-symbols hingeschreiben daß es durch --enable-crashdump
aktiviert wird.
> > | * configure --help should include the valid choices for
> > | --enable-crashdump (that is yes, TRUE, STATIC, no)
>
> ja, das hatte ich vergessen.
Nein, nicht nur das.
> > | * when --enable-crashdump=STATIC (or none) was given, configure should
> > | not give "no" as result (do not print "Checking whether to enable
> > | crashdump feature... no")
>
> Das hatte ich in dem einen commit aus versehen vergessen.
Nee, das war schon beim ersten Mal OK.
> > Wenn Du das als unkonkret empfindest kann ich Dir nicht helfen.
>
> *Einiges* von dem war unkonkret. Nicht alles. Zum Beispiel sagtest Du nicht
> *wie* Du es haben willst und hast dann danach am commit rumgemeckert.
Klar meckere ich rum. Erstens war ja der commit nicht das was ich
gefordert hatte (nicht mal annähernd), zweitens hast Du die Angewohnheit
nicht zu schreiben wie Du etwas fixed - deshalb kann man nur im
Nachhinein rummeckern.
> Egal, der Issue war ein Musterbeispiel von Misverständnissen. Es wäre
> trotzdem
> einfacher gewesen, Du hättest von Anfang an einen Patch geschickt, den ich
> einfach applyen haette koennen...
Fürs nächste mal. Schreib halt beim nächsten mal gleich "send a patch".
Ich hab ja mehrmals meine Wünsche erläutert und auch gefragt:
,----
| Happy now? If not, please give clear instructions.
`----
> [...]
> In der letzten Zeit habe ich deswegen ein wenig schlechte Laune. Sorry.
> Ich denke, wir sollten das Kriegsbeil begraben...
Wenns nach mir ginge hätten wird das erst gar nicht ausgegraben.
Wenn Du es noch hinbekommst trotz signatur einen Zeichensatz zu
deklarieren, dann kann das Beil in Frieden ruhen..
> [...]
ciao
Christian
--
NP: Waltari - Slow Thinking Street
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
