Re: Reproduzierbare Erstellung
#include <hallo.h>
Klaus Knopper wrote on Sun May 13, 2001 um 10:40:02PM:
> > Das ist mehr oder weniger einfach:
> > Das "task-knoppix" Paket enthält Abhängigkeiten von allen benötigten
> > Paketen. Will man später eine CD "reproduzieren", setzt man eine
> > chroot-Umgebung auf, setzt die gewünschten Distributions-Pfade in
> > "sources.list" und lässt "apt-get task-knoppix" laufen. Dann werden
> > automatisch alle Pakete mit den benötigten Dep's heruntergeladen.
>
> Habe ich noch nicht ganz verstanden, was dies mit chroot zu tun hat.
> Hört sich aber gut an. ;-)
chroot ist ein einfacher und beliebter Weg, sich mehrere
Debian-Umgebungen auf der Platte zu halten. Ich habe z.B. ein
chroot-Verzeichniss für stable, in dem ich meine Pakete für Potato
kompiliere. In einem frisch aufgesetzten 'chroot' kann man auch gut
testen, ob man alle Build-Depends berücksichtigt hat.
> > rauskommt sind Standard-konforme DEBs, d.h. z.B. kompilierte
> > ALSA-Module, die mit den gleichzeitig erzeugten Kernel-Image eingesetzt
> > werden können. Auch das Kernel-Paket ist ein "richtiges"
> > Debian-Kernel-Paket mit eingebauter LILO-Boot-Loader-Installationroutine
> > u.ä.
>
> Hmm.. Was ist mit so Sachen wie reiserfsutils, pcmcia(-utils)? Das sind nicht
> direkt Module, die brauchen aber schon die Includes des gleichen Kernels.
Richtig. Das sind Source-Pakete, die nach /usr/src/modules kommen.
make-kpkg baut daraus dann die binären Modul-Pakete und benutzt dabei
installierten Includes. D.h. die erzeugten Modul-Pakete sind dann auf
den gleichzeitig erzeugten Kernel abgestimmt.
> Gibts irgendwo eine Anleitung, wo drinsteht, wie dieses debian-Paketsystem
> funktioniert? Der "New Maintainers Guide" ist ziemlich unbrauchbar, finde ich.
/usr/share/doc/{debian,debian-policy,developers-reference,maint-guide*,dev}
- FAQ, Policy, FHS, Dev.-Reference, steht alles irgendwo dal
> > "task-knoppix-dev", dass Abhängigkeiten zu den genannten Source-Paketen
> > und ähnlichen, evtl. benötigten Dingen führt.
>
> Aber solche Sachen wie cloop.o müssen zum aktuellen Kernel passend compiliert
> werden. Einfach Binaries abkippen ist da nicht.
Da können wir mit cloop auch ein Source-Paket nach dem oben
beschriebenen Muster bauen.
> Und die Bootdiskette ist wieder ein Thema für sich, da müssen ja auch die
> passenden Module zum Kernel bzw. der Kernel selbst und eine ash mit eingebautem
> insmod (Redhat-SRC-RPM habe ich) drauf.
Das wird interessant... Aber es lässt sich bestimmt automatisieren.
> Im Bootscript linuxrc passiert viel mit Variablen, und einige Sachen werden
> in /etc/sysconfig/subsystem registriert (argh, das gibt's unter Debian ja auch
> nicht!!!)
Noch nicht ;)
> Ich bin halt immer von einem "normalen" System ausgegangen, und da sollte
> unter /usr kaum schreibbares Zeug liegen, dafür einiges in /var (was auf der
> Ramdisk ist) und /etc (was auch auf der Ramdisk ist), und es müssen ein Haufen
> Softlinks geseztz werden. Das IST eben distributionsspezifisch.
Ja, ist es wohl. Das wird halt die lästige Handarbeit.
> Ich hatte die KNOPPIX-Initscripte bisher einfach in einem anderen Verzeichnis
> in /etc als die normalen. Leider sind ja bei Debian auch wieder die
> Runlevelverzeichnisse anders als woanders...
Das ist bei den meisten Distributionen "woanders".
> Also ich relativiere mal das "unmöglich" in "ich weiss nicht, wie es geht, bin
> aber lernfähig, glaube aber nicht, dass wir den Automatismus bis zu dem Termin,
> an dem die CD ins Presswerk muss, fertig bekommen".
Wann ist denn der Termin? Mitte Juni oder so?
> > Ja. Dafür würde ich eine kleine Datenbank anlegen.
>
> Die wird nicht klein sondern ziemlich gross und muss von allen Betatestern
> zugreifbar sein. Mailingliste besser?
Rsync oder CVS?
> > Für libkudzu hab ich ein ITP gesehen, ich würde die Person fragen, ob er
> > evtl. schon Snapshots davon zur Verfügung stellt.
>
> Wenn mir das Source-Paketsystem von Debian etwas klarer wäre, könnte ich sicher
> auch selber das Paket paketieren. Evtl. lohnt es sich auch, hwsetup für die
> libdetect umzuschreiben, die ja anscheinend von Debian bevorzugt wird.
Ich kenne mich da nicht so aus, was die Hardware-Erkennung angeht.
> Allerdings weiss ich nicht, wie stabil die ist. Kann die auch Monitorfrequenzen
> proben? (das schafft nämlich dir libkudzu noch nicht), und wie sieht es mit
> Grafikkartenerkennung aus?
Monitor-Frequenzen proben ist eine heisse Angelegenheit. Bist du drüber,
schaltet sich das Ding ab, oder raucht ab, oder macht eine Pause bis man
Aus- und Einschaltet etc.
> > Amsonsten:
> > satan - Security Auditing Tool for Analysing Networks
> > libnasl-dev - Nessus Attack Scripting Language, static library and headers
> > libnasl1 - Nessus Attack Scripting Language, shared library
> > libnessus-dev - Nessus static libraries and headers
> > libnessus1 - Nessus shared libraries
> > nessus - Remote network security auditor, the client
> > nessus-dev - Nessus development header files
> > nessus-plugins - Nessus plugins
> > nessusd - Remote network security auditor, the server
> > smpeg-plaympeg - SMPEG command line MPEG audio/video player
> > smpeg-xmms - SDL MPEG Player Library - XMMS plugin
> >
> > Geht nicht, gibt's nicht.
>
> WO finde ich diese Sachen denn?! apt-cache search findet die alle nicht.
Das war apt-cache search, allerdings auf Unstable.
> Kann man die in einer Form bekommen, so dass man sie auf der "stable"
> Debian 2.2 compilen kann, ohne dass man alle möglichen Developer-Pre-Alpha-Libs
> installieren muss?
apt-get source <paket>
cd neues-verzeichniss
dpkg-buildpackage -us -uc -rfakeroot
Vorher noch die Build-Dependencies in debian/control untersuchen, evtl.
ein Paar Libs (in der Potato-Version) installieren. Wenn die Lib noch
nicht da ist, oder zu alt, dann halt zuerst diese Lib rekompilieren.
Insgesammt ist es relativ umständlich, ich würde gleich die Testing
nehmen.
> > Moment, vergleichst du da etwa Potato mit einer aktuellen RedHat? Nimm
> > lieber Testing (Woody), das entspricht eher dem Umfang, aber auch der
> > Stabilität.
>
> Falls instabile Pakete dabei sind, können wir die mit einer hinreichend langen
> Betatestphase alle eliminieren bzw. neu bauen. Aber das Grundsystem sollte
> stabil sein (Kernel, Libs, X-Server, Sysutils), und die netten Gimmicks und
Ich würde zumindest die wichtigsten Sachen aus Testing nehmen. Ist halt
nicht so ganz stabil wie Potato, da lediglich 2 Wochen Testphase, aber
IMHO ausreichend.
> > Oh Mann, hätte ich Zeit, würde ich euch gerne helfen. Ich tippe eher auf
> > wenige Wochen, aber das Studium ist im Moment ziemlich ätzend.
>
> Kleiner Tipp: Das bleibt auch bis zum Studienende so. ;-)
Danke ;)
> > Meinst du? Nur so als Beispiel: Debian's "base"-System wird auch so
> > automatisch gebaut, und es schein zu funktionieren, mehr oder weniger.
>
> Ist das irgendwo dokumentiert?
Keine Ahnung. Du kannst dir per CVS den "boot-floppies" Tree ziehen (ist
irgendwo dokumentiert), dann dort mit dpkg-buildpackage oder so. Weiss
auch nicht mehr.
> Also, es gibt ab dem Moment, wo init startet, 2 bis 4 Partitionen:
>
> /KNOPPIX 1.5 Gig, über cloop gemountet von CD, read-only
> da liegt ALLES drauf, was nicht unbedingt schreibbar sein muss.
> Softlinks in / zeigen auf /KNOPPIX/usr, /KNOPPIX/bin usw.
> / Ramdisk, 4 MB (rw), da liegt auch /etc drauf
Klar. Ich habe früher ähnliches mit Plattenlosen NFS-Clients gemacht.
> /home Ramdisk, variable Größe, kann auch auf / sein, falls nicht genug
> Hauptspeicher vorhanden.
> /var Ramdisk, variable Größe, siehe /home. Alles, was NICHT schreibbar sein
> muss, wird per Softlink von /KNOPPIX verlinkt.
>
> Ob diese Einteilung sinnvoll ist, mag diskutiert werden. Sie läuft
IMHO okay.
> > Glaube ich nicht, weil sich alle Maintainer an die FHS zu halten haben,
> > und das kann sehr wohl automatisch verarbeitet werden.
>
> Ist /cdrom unf /floppy wirklich Filesystemstandard?! Was ist denn bei mehreren
FHS sagt nichts dazu, aber das war IIRC eine lange Zeit der
Quasi-Standard.
> CD-Roms, heissen die dann auch /cdrom1, /cdrom2 ... oder werden die, wie ich es
> von Redhat-Systemen her kenne, als Unterverzeichnisse von /mnt gemountet?
Wie du willst. Bei mir macht es der automounter unter /mnt/teac,
/mnt/ricoh usw.
> > Was zu
> > - umständlichen Logs führt, wo dann doch jemand einen wichtigen Eintrag
> > vergisst, und
> > - irrsinigen, immer zu wiederholenden Aufwand.
>
> Hier fehlt mir noch der entscheidende Hinweis, wie wir das einfacher
> hinbekommen ohne Handarbeit.
Gar nicht. Einmal muss man das machen.
> > Ich komme mal vorbei. Hast du Zeit am Montag, ab 15:30, oder Dienstag,
> > ab 14 Uhr?
>
> Dienstag habe ich von 16-18:000 Uhr Kurs am RHRK, und 14:00 Uhr ist ein
> bisschen früh für mich. Ich versuche mal, am Montag um 15:30 Uhr im
> Linuxtag-e.V. Raum zu sein.
Dann bis morgen.
MfG,
Eduard.
--
==========================================================
Eduard Bloch <blade@debian.org> | GnuPG: 0xEDF008C5(GnuPG)
"Die Erfahrungen sind wie die Samenkörner, aus denen die Klugheit
emporwächst." (Konrad Adenauer)
Reply to: