Mailinglist Archive: opensuse-de (696 mails)

< Previous Next >
Re: wie für 32bit über setzen?
  • From: David Haller <lists@xxxxxxxxxx>
  • Date: Sun, 16 Aug 2009 23:19:19 +0200
  • Message-id: <20090816211919.GA29190@xxxxxxxxxxxxxxxxxx>
Hallo,

Am Son, 16 Aug 2009, Sebastian Siebert schrieb:
David Haller schrieb:
Erstmal: dieses und ähnliche Themen gehören _eindeutig_ auf
opensuse-programming-de.
X-Mailed & F'up dahin.

Sach mal, hast du das überlesen?

Das war mehr als nur eine dezente Bitte.

Am Son, 16 Aug 2009, Sebastian Siebert schrieb:
[..]
Ich würde dir OBS (openSUSE Build Service) ans Herz legen.
<https://build.opensuse.org/>

Die Pakete kannst du entweder öffentlich zugänglich machen oder auch
nicht. Du musst dich nur einmal intensiv mit OBS auseinander setzen.
Danach geht es verdammt schnell mit dem Paketbau. *Versprochen* :-)

Naja, nur wenn alles passt. Wenn's mal hakt, dann gerne kräftig.

Wenn du irgendwelche System-Libraries meinst, die im System tief
verankert. Dann ja.

Du willst alle nicht-System-Libraries selber mit in deinem OBS-Project
mit kompilieren? Das arme OBS.

Falls du mit dem Schreiben einer SPEC-Datei nicht so bewandert bist.
Dann würde ich dir empfehlen, eine SPEC-Datei aus irgendeinem
OBS-Project zu entnehmen und diese dann anpassen.

Selbst wenn's lokal durchläuft, das rpmlint erfordert meist noch
diverse (sinnvolle) Änderungen am Spec oder Patches an den Sourcen und
und und. Und das ggfs. je nach SuSE-Version unterschiedlich.

Bisher ist es zu meinen Gunsten gelaufen. Nur Glück oder vom Upstream
sauber programmiert, wobei ich eher Letzteres tippe.

Sehr, sehr wahrscheinlich letzteres. _Und_ Glück ;)

Selbst für sehr erfahrene .spec-Bastler wie mich hält das OBS einige
unschöne Überraschungen bereit, für deren Behebung man je nach Fall
einiges an Erfahrung mit .specs, make (oder was auch immer), und der
Programmiersprache braucht.

Besonders spaßig wird's mit Build-Programmen, die sich nicht so
einfach wie make auch via (Umgebungs-)Variablen steuern lassen.

Guck dir mal nur die Schweinereien mittels 'sed' in
https://build.opensuse.org/package/view_file?file=freemedforms.spec&package=freemedforms&project=home%3Adnh%3Atesting
an. Und 'qmake' generiert immerhin noch normale Makefiles.

Ah, David, diese Schweinerei hast du dem Upstream-Autoren zu verdanken,
dass diese nicht die notwendige Flexibilität verbauen, dass hat mit OBS
wenig zu tun.

Eben. Vom Upstream kommt viel, das "Schweinkram" erforderlich
macht. In jeder neuen Version wieder (anders).

Aber das OBS verhindert (praktisch), daß man sowas einfach mal
systemweit flicken kann, sondern das jedesmal im Spec machen muß.

imake ist auch noch rel. pflegeleicht, dito meist die Perl-Varietäten
(Makefile.PL / Build.PL). Bei denen kann man vieles per make VAR= oder
zur Not make -e VAR= anpassen.

Meist stehen diese Anpassung in diversen Readme-Dateien oder auf der
Webseite vom Upstream, wie man was ändert. Manchmal kann man gar nichts
ändern und muss sich mit einigen Patch-Dateien behelfen. Dies ist
normal und macht jede andere Distro auch. In diesem Fall muss man sich
an das Upstream wenden, um besser Anpassungsfähigkeiten zu ermöglichen.

Ich hab nix gegen patches. Aber nur um $prefix oder LDFLAGS zu ändern?

Aber dann guck dir mal cmake, bjam, IIRC smake, ... an. Da sind
irgendwelche Flags für den Compiler hart verdrahtet, oder im besten
Fall in irgendwelchen *systemweit gültigen* Files hinterlegt und nicht
per Kommandozeile änderbar, die aufgrund irgendwelcher Dinge dann
gesetzt werden. Und im OBS kannst du die Systemweiten nicht anpassen!
Da kannst du gar nicht so viel fressen wie du kotzen willst.

Wende dich an die Leute vom Upstream. Man kann gar nicht genug
wiederholen. :-)

Du meinst, die boost-Leutkens würden wg. mir von bjam auf automake
umsteigen?

Die automake / autotools / make mögen ein großer Haufen Dreck sein (so
bezeichnen sie einige), aber ich als (u.a.) Paketbauer kann da
weitgehend und meist _einfach_ steuern, wie eine bestimmte Datei
gebaut wird, dank weitgehend standardisierter Variablen wie CFLAGS,
CXXFLAGS, LDFLAGS, DESTDIR usw. Ich ziehe die autotools, trotz der
Macken letztlich vor.

Von automake oder autotools sollte man mit Abstand genießen. Da evtl.
wichtige Flags überschrieben werden. Hier muss man 3 Mal kontrollieren,
ob wirklich alles richtig gelaufen ist.

Ist immer noch viel einfacher. Und überschreiben muß man i.d.R. gar
nichtmal, da es bei sauber generierten Makefiles Variablen gibt, über
die man gezielt seine Flags reinbringen kann.

Und portabel ist der Kram auch noch. Ich hab mal wget unter Win95 mit
den Buildtools vom Visual Studio 4 oder so gebaut. Ging. Einfach so.
./configure, nmake, nmake install (oder install per Hand, weiß
nimmer). Shell war IIRC cygwin-bash.

Wenn es keine große Abhängigkeiten gibt, dann haben die vom Upstream
gute Arbeit geleistet, dass es wenigstens läuft. :-)

Jup. wget ist sauber.

Und wenn ich mir die ellenlangen Dateien von cmake / bjam in den
Verzeichnissen so angucke ... Und wie ewig lang (>>10 min) bjam hier
rumeiert, bevor es auch nur das erste Mal den Compiler anwirft (bei
libboost), und dann auch noch scheinbar ziemlich kaputte
Abhängigkeiten der Sourcen/Objects zu haben scheint ...

Mit libboost kann ich auch was erzählen. Da gab es ein "hash resize"
bug, der jetzt behoben wurde. Ich bin für den Paketbau von PokerTH
zuständig und dieses Paket benötigt halt libboost. Das PokerTH-Team
(Upstream) hat mir mitgeteilt, dass das libboost 1.39 ein Fehler hat.

Oha. PokerTH. Verwende ich...

Wobei der Server von PokerTH abkratzen kann. Hört sich schlimm an, ist
aber mit einem Patch schnell behoben. Ich habe bereits ein Fehlerpatch
an das OBS-Team der Factory gesendet und habe es eingepflegt. So, und
wenn noch was kaputt ist, dann wende dich an das Upstream. (Habe ich das
nicht eben schon gesagt?!) In dem Fall war es beim Upstream der Fehler
bekannt und ein Patch stand zu Verfügung.

libboost ist IMO v.a. nervig. Nervig zu kompilieren (klappt hier mit
keiner bisher probierten 1.3x Version, weder mit gcc-2.93.3, noch
3.3.5), nervig den von diversen Programmen (angeblich) geforderten
Versionen hinterherzuhecheln ...

AFAIK fluchen auch die Packager der Versionen der OpenSUSE Releases
gerne mal über libboost ...

... ist mir ein simples Makefile.am dann doch lieber. Und die
Makefile.in / Makefile haben eine wohldefinierte Struktur, die sich
aus den Makefile.am ergibt, d.h. auch als Paketbauer reicht es meist
nur ins .am zu gucken.

Das wahrlich die einfachste Lösung, wenn der Upstream halt sauber
gearbeitet hat.

Bei autotools/automake kann man das recht einfach auch noch per
Kommandozeile oder patch (von configure, aclocal.m4, ...) _zentral_
aber lokal, auch im OBS, reparieren, da es eine build-lokale Datei
betrifft. Aber wie willst du (als non-root-build) sauber in
/usr/{lib,share}/irknwas was patchen?

Äh, *ups*, da bin ich wohl etwas vom Thema abgekommen. Jedenfalls:
deine Empfehlung das OBS zu verwenden ist, ähm, etwas eigenwillig.

Ist nicht eigenwillig, sondern man kann es durchaus verwenden. Nur
muss man sich wie bei jeder Distro auf Probleme einstellen und mit
dem Upstream in Kontakt halten.

Der OP schrieb IIRC nix von nem .spec, das er schon hätte.

Weiß du, welches Paket er meint? Nein. Daher frag ihn doch mal. ;-)

Nö. Und Upstream?

Weiter bitte auf opensuse-programming-de.

Nö, ist für mich hier schon beendet, was ich gesagt habe, habe ich
nun gesagt. :-)

Wann'st moanst ...

-dnh

--
[Der] HTML-Checker findet sich unter http://validator.w3.org/, alles was da
nicht durchkommt, ist fehlerhaft und hat im Internet nichts verloren.
-- Manfred Tremmel
--
Um die Liste abzubestellen, schicken Sie eine Mail an:
opensuse-de+unsubscribe@xxxxxxxxxxxx
Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken
Sie eine Mail an: opensuse-de+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups