// Datei: ./praxis/pakete-bauen-mit-checkinstall/vor-und-nachteile.adoc

// Baustelle: Rohtext

=== Vor- und Nachteile ===

Erwartungsgemäß wird die Verwendung von `checkinstall` im Alltag von
Entwicklern, Paketmaintainern und Benutzern gemischt bewertet. 

'Entwickler' und 'Paketmaintainer' sehen das Werkzeug überwiegend
positiv -- haben Sie darüber nämlich die Möglichkeit, auszutesten, ob
sich die von Ihnen verwendete Entwicklerversion nahtlos in das
bestehende Debian-Ökosystem einspielen läßt und mit den anderen Paketen
harmoniert. Die Paketverwaltung hat eine Information darüber, daß Sie
ein zusätzliches Paket als solches installiert haben. Sollte das Paket
unerwartete Querschläger produzieren, kratzen Sie es auch wieder ohne
viel Aufwand und vorallem restefrei vom System herunter. Das erlaubt
Ihnen automatisierte Integrationstests im Rahmen der Qualitätssicherung.

// Stichworte für den Index
(((Maintainer-Skripte, postinst)))
(((Maintainer-Skripte, preinst)))

Verschwiegen werden sollen jedoch nicht die Nachteile. Ein mittels
`checkinstall` generiertes und eingespieltes Paket unterläuft die
strenge Qualitätskontrolle von Debian. Die übliche Validierung durch
andere Tester und Benutzer sowie eine Erzeugung von Prüfsummen findet
ebenfalls nicht statt. Die Paketabhängigkeiten werden nur bedingt
validiert, d.h. nur auf dem System, auf dem das Paket erzeugt und
eingespielt wurde. Das Ergebnis -- sprich das erzeugte `deb`-Paket --
ist nicht unbedingt portabel und stets eins-zu-eins auf andere
Debian-Installationen übertragbar. Berichtet wird ebenfalls, daß
`checkinstall` nicht bei Programmen funktioniert, die statisch gegen die
`libc` linken, oder bei solchen, bei denen das SUID/GUID-Bit gesetzt ist
(siehe <<Drilling-Checkinstall-LinuxUser>>). Ebenso sind Probleme mit
den `preinstall`- und `postinstall`-Skripten bekannt (siehe
<<Schnober-Checkinstall-LinuxUser>>).

Aus Sicht der 'Benutzer' ist es sicherlich sehr erfreulich, wenn eine
Lücke in den benötigten Komponenten geschlossen wird. Was sie meist
weniger einschätzen können, ist die Stabilität der Lösung und der
Aufwand seitens der Entwickler und Paketmaintainer, um diese Lösung
dauerhaft zu betreuen und den Weiterentwicklungen anzupassen.

Aus den oben genannten Gründen empfehlen wir Ihnen, den Einsatz von
`checkinstall` genau zu überdenken. Als nützlich und hilfreich schätzen
wir es insofern ein, daß Sie in einem Schritt überprüfen können, ob ein
Stapel Software ``baut'', sich ein Paket daraus schneidern läßt und
dieses mit dem restlichen Debian-Ökosystem zusammenarbeitet. Das
erleichtert Ihnen die Integrationstests und sollte nachfolgend die Basis
dafür bilden, daraus ein richtiges Paket entsprechend den
Debian-Paket-Standards zu erstellen. Bis das soweit ist, steht einer
Benutzung auf lokalen Rechnern und Einzelsystemen -- bspw. im Rahmen
einer ``Testinstallation'' -- nichts im Wege. Einem großflächigen
Alltagsbetrieb des erzeugten Pakets stehen wir skeptisch gegenüber.

==== Weitere noch unbearbeitete Notizen ====

* Vorteile:
** installiert automatisch die zusätzlichen, bisher noch nicht installierten Header-Files nach
*** stimmt das?

// Datei (Ende): ./praxis/pakete-bauen-mit-checkinstall/vor-und-nachteile.adoc
