[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Vortrag über Paketbau



Daniel Leidert <daniel.leidert.spam@gmx.net> wrote:
> Am Freitag, den 17.06.2005, 21:15 +0000 schrieb Joerg Sommer:
>> Daniel Leidert <daniel.leidert.spam@gmx.net> wrote:
>> > Seite 3:
>> > - dahinter steht in diesem Fall nicht dpkg, sondern dpkg-deb ('dpkg -c
>> > paket.deb' ruft 'dpkg-deb -c paket.deb' auf) - evtl. in Klammern hinter
>> > dpkg vermerken (man dpkg-deb)
>> 
>> Ich hab es umgekehrt gemacht. Ich habe dpkg-deb genutzt und erwähnt, dass
>> dpkg die Argumente durchreicht.
>
> So ist ja auch richtig.
>
>> Ist geplant, dass dpkg diese Optionen irgendwann nicht mehr unterstützt?
>
> Nicht dass ich wüsste. Aber 'man dpkg' wird dem interessierten Leser
> nichts zu den von dir vorgestellten Optionen berichten.

Bei mir:
,----[ man dpkg ]---
|   dpkgan be also be used as a front-end to dpkg-debhe following are
|   dpkg-debctions, and if they are encountered, dpkgust runs dpkg-deb
|   with the parameters given to it:
|       -b--build
|       -c--contents
|       -I--info
|       -f--field
|       -e--control
|       -x--extract
|       -X--vextractnd
|       --fsys-tarfile
|   Please refer to dpkg-deb) for information about these actions.
`----

>>>  [Logdateien löschen oder nicht?]
>> Ich werde mal suchen. Aber ich bin nicht der Meinung, da nach einem
>> --purge das System wieder so aussehen sollte, wie vor der Installation.
>
> Naja, eigentlich besteht der große Unterschied zwischen 'purge' und
> 'remove' doch im Löschverhalten der Konfiguraionsdateien.

Eben. Wenn sich der Benutzer schon dafür entscheidet, dass er die
Konfigurationsdateien weg haben will, dann kann man die Logs auch mit
löschen.

> Logs würde ich nicht löschen, eben weil es Logs sind und sie auch nach
> der Deinstallation eines Pakets noch gebraucht werden.

Jein. Hier in dem Fall kann ich mich glücklicher Weise darauf berufen,
dass die Logs ohne das Paket nutzlos sind. Es sind einfach nur vom
Paket generierte Dateien(, die eigentlich nach /var/lib/ gehören).

>> Warum? Ich bin auch dagegen, dass clean z.B. auf root testet. Ich auch
>> schon einmal eine Diskussion mit einem Maintainer, der sich dann
>> einfach auf dh_make berufen hat. Ich sehen keinen Grund, warum man
>> root-Rechte zum Löschen braucht. Auch configure könnte ohne root-Rechte
>> auskommen.
>
> Prinzipiell richtig. Die Diskussion würde ich dann aber nicht mit
> ahnungslosen[tm] Zuhörern führen ;). Der Hinweis war mehr
> grundsätzlicher Natur. Wenn du weiß, was du tust, spricht sicher nichts
> dagegen, an dieser Stelle auch ohne fakeroot zu arbeiten.

OK, akzeptiert. Das ist ein Argument. Ich werde das im Vortrag nochmal
überarbeiten, weil genau das, was du gesagt hast, der Standardfall ist.

>> > - Debian library packaging guide
>> 
>> Dazu hab ich keinen Link gefunden.
>
> Echt? Einfach copy&paste zu Google und es ist der erste Link.

Ich hab apt-cache bemüt.

>> Ich hab gestern noch lintian darauf angesetzt und musste feststellen,
>> dass es nicht in Ordnung ist, ein Verzeichnis in /mnt/ anzulegen.
>> bootchart braucht aber ein Verzeichnis, dass zum Zeitpunkt, wenn init
>> startet, verfügbar ist. /usr/ und /var/ fallen also raus.
>
> Warum fällt /var raus

Weil es nicht zwingend nach dem Start von init zur Verfügung stehen
muss. Der FHS gibt die Möglichkeit, dass man es später per NFS oder
anderswie einbindet.

> (ich kenne mich im Bootprozess nicht so wahnsinnig gut aus)? Würde
> evtl. auch ein Verzeichnis in einem temorären FS funktionieren, dass
> dann nach /var kopiert wird?

So wird es auch gemacht. Es wird ein tmpfs nach /mnt/bootscript
gemountet und die Daten von dort werden dann nach /var/log/ kopiert.

Jörg.
-- 
Als deutscher Tourist im Ausland steht man vor der Frage, ob man sich
anständig benehmen muss oder ob schon deutsche Touristen dagewesen sind.
	  	   	     	      	        (Kurt Tucholsky)



Reply to: