Debian gcc 9.1 package / auto tools

René H. schrieb:
> Neue .spec Files schreiben macht mich jetzt nicht besonders an.

Du kannst die von einem ähnlichen Packet als Vorlage nehmen.

Aber du kommst nicht drumherum exakt alles zu prüfen, niemand mag 
schnell hingepfushte Pakete die nicht richtig funktionieren. Ist halt 
schon etwas an Arbeit was man dort rein stecken muss.

Daniel A. schrieb:
> Ahm... Debian nutzt .deb, nicht .rpm.

Mist, natürlich, sorry, auf der Arbeit arbeiten wir mit RHEL deshalb die 
Verwechslung.

Daniel A. schrieb:
> Und wenn du ein neues Packet da rein bringen willst, musst du:
>  1) Die Packaging Daten erstellen (das, was im  debian/ verzeichnis
> ist), anlegen.
>  2) Das muss sich dann auf einem frischen System mit "apt-get build-dep
> .; debuild -us -uc" builden lassen
>  3) Du lädst nur die source packages hoch, nicht das binär zeug. Das
> wird dann von debians build servern gebaut.
>  4) Du musst als Maintainer das Packet dann bei Problemen auch jeweils
> wieder in stand bringen, sonst ist es schnell wieder draussen.

Ja, damit habe ich Erfahrungen, von mir sind ein paar Printertreiber in 
Ghostscript und ein Kernel Modul zu finden. Nur mit Debian kenne ich 
mich noch nicht aus (ich hatte immer SuSE),

Daniel A. schrieb:
> Früher oder später übernehmen das dann auch die Derivate,
Stimmt, es spricht nichts dagegen dass ich das bin :-).
Danke Dir für die Informationen, ich werde das versuchen.

Bernd K. schrieb:
> checkinstall

Wird gerade installiert, ich gebe bescheid, Danke Bernd.

Grüsse
René

René H. schrieb:
>> checkinstall

Scheint das zu machen was ich will, danke (kannte ich noch nicht). Ich 
habe das make install aber bereits gemacht.

Ein checkinstall -D --install=no

liefert Fehlermeldungen, dass die Header Dateien bereits existieren.

Hast Du einen Tipp?

Grüsse,
René

Bezüglich checkinstall: das ist ’ne quick&dirty-Lösung. Und zwar so 
schmutzig, dass man damit erstellte Pakete nicht der Allgemeinheit zur 
Verfügung stellen möchte. Das erstellte Paket funktioniert, wenn 
überhaupt, u.U nur auf dem eigenen System, und das auch nur, solange 
sich nicht zuviel bei den Sachen ändert, von denen es abhängt.

zufaulzumanmelden schrieb:
> Bezüglich checkinstall: das ist ’ne quick&dirty-Lösung. Und zwar so
> schmutzig, dass man damit erstellte Pakete nicht der Allgemeinheit zur
> Verfügung stellen möchte. Das erstellte Paket funktioniert, wenn
> überhaupt, u.U nur auf dem eigenen System, und das auch nur, solange
> sich nicht zuviel bei den Sachen ändert, von denen es abhängt.

Ok, verstanden. Es sind gesamt 5 Packges zu machen. Ich werde mich wohl 
oder übel mit Debian Packges auseinandersetzen müssen. .spec kenne ich, 
von Debian habe ich noch keinen Plan.

Grüsse,
René

Bernd K. schrieb:
> dann sehe ich nicht warum das dann so erzeugte Paket eine mindere
> Qualität haben sollte

- Evtl. fehlen Patches die das die Software Debian konform macht?
- Evtl. legt die Software im Betrieb Dateien an die bei der 
Deinstallation auch gelöscht werden wollen?
- Evtl. will man Dateien für cron, logrotate installieren?
- Evtl. will man die Software ins Startupsystem einbinden (init.d, 
upstart usw.).
- Evtl. will man für die Software Nutzer/Grupprn anlegen?
- Evtl. braucht die Software Einträge für sudo oder udev?

So als Beispiele...

Ich hoffe ich habe die richtigen Paketquellen erwischt...
https://salsa.debian.org/toolchain-team/gcc-defaults/tree/master/debian

So ein Packet möchte ich nicht selbst von Grund neu erstellen wenn ich 
nicht unbedingt muss.

Ich würde diese Paketquelle nehmen und auf meine Bedürfnisse anpassen, 
wenn es aus irgendeinem Grund notwendig wäre.

Ups, eher hier...
https://salsa.debian.org/toolchain-team/gcc/tree/gcc-7-debian/debian

Da muss man sich dann wohl doch eher mit ernsthaften Interesse einlesen 
um erstmal zu verstehen wie das alles zusammenspielt.

test schrieb:
> Bernd K. schrieb:
>> dann sehe ich nicht warum das dann so erzeugte Paket eine mindere
>> Qualität haben sollte
>
> - Evtl. fehlen Patches die das die Software Debian konform macht?
> - Evtl. legt die Software im Betrieb Dateien an die bei der
> Deinstallation auch gelöscht werden wollen?
> - Evtl. will man Dateien für cron, logrotate installieren?
> - Evtl. will man die Software ins Startupsystem einbinden (init.d,
> upstart usw.).
> - Evtl. will man für die Software Nutzer/Grupprn anlegen?
> - Evtl. braucht die Software Einträge für sudo oder udev?
>
> So als Beispiele...

Trifft alles auf gcc nicht zu. Ich habe es erst mal in /usr/local 
installiert.
Das Package müsste dann sicher in /usr.

Ich werde sicher darauf achten ein sauberes Package abzuliefern.

Grüsse,
René

Insbesondere solltest du drauf achten, dass es nicht mit ‘nem gcc-8.3 
(derzeit in Stable) kollidiert, das seine Sachen ebenfalls unter /usr 
ablegt, und für den Betrieb mancher Sachen zwingend notwendig ist, und 
daher nicht einfach so deinstalliert werden kann.

Auch wäre drauf zu achten, dass der ganze Kram um gcc herum (libc et al) 
nicht angefasst wird, weil das u.U. das gesamte System zerlegen würde.

Gerade bei so einem zentralen Paket ist’s nicht trivial, das ordentlich 
hinzubekommen. Zusätzliche Installation nach /opt oder eben /usr/local 
wäre okay, allerdings müssen dann, um’s zu nutzen, auch diverse Pfade 
angepasst werden – was wiederum zu oben angedeuteten Problemen führen 
kann.

Am einfachsten (aber nicht besonders flexibelsten) fand ich den Paketbau 
auf Debian mit equivs. Dabei legt man sich mit `equivs-control 
<controldatei>` eine "Steuerungsdatei" an und passt sie nach eigenen 
Bedürfnissen an. Mit `equivs-build <controldatei>` kann man dann eine 
.deb erstellen.