path: root/man/sv/dpkg-maintscript-helper.pod

        *****************************************************
        *           GENERATED FILE, DO NOT EDIT             *
        * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION *
        *****************************************************

This file was generated by po4a(7). Do not store it (in VCS, for example),
but store the PO file used as source file by po4a-translate.

In fact, consider this as a binary, and the PO file as a regular .c file:
If the PO get lost, keeping this translation up-to-date will be harder.

=encoding UTF-8

=head1 NAMN

dpkg-maintscript-helper - går runt kända dpkg-begränsningar i paketskript

=head1 SYNOPS

B<dpkg-maintscript-helper> I<kommando> [I<flagga>...] B<-->
I<maint-script-flagga>...

=head1 KOMMANDON OCH PARAMETRAR

=over 

=item B<supports> I<kommando>

=item B<rm_conffile> I<konffil> [I<tidigare-version> [I<paket>]]

=item B<mv_conffile> I<gammalkonffil> I<nykonffil> [I<tidigare-version>
[I<paket>]]

=item B<symlink_to_dir> I<sökväg> I<gammalt-mål> [I<tidigare-version> [I<paket>]]

=item B<dir_to_symlink> I<sökväg> I<nytt-mål> [I<tidigare-version> [I<paket>]]

=back

=head1 BESKRIVNING

Programmet skrevs för att köras i paketskript för att utföra en del åtgärder
som B<dpkg> (ännu) inte själv kan hantera, antingen på grund av designval
eller på grund av nuvarande begränsningar.

Många av dessa åtgärder kräver samordnade åtgärder från flera paketskript
(B<preint>, B<postinst>, B<prerm>, B<postrm>). För att undvika misstag
räcker det att lägga in ett och samma anrop i alla skript, varpå programmet
anpassar sitt beteende beroende på miljövariabeln B<DPKG_MAINTSCRIPT_NAME>
och på paketskriptets parametrar, vilka du måste vidaresända efter dubbla
bindestreck.

=head1 DELADE PARAMETRAR

=over 

=item I<tidigare-version>

Anger den senaste version av paketet vars uppgradering ska orsaka
händelsen. Det är viktigt att beräkna I<tidigare-version> korrekt så att
operationerna utförs korrekt även om användaren byggt om paketet med en
lokal version. Om I<tidigare-version> är tom eller utelämnas försöks
operationen vid varje uppgradering (notera: det är säkrare att ange
versionen och endast försöka utföra operationen en gång).

Om konffilen inte har sänts med i flera versioner och du nu uppdaterar
utvecklarskripten till att städa bort den gamla filen bör
I<tidigare-version> baseras på den version av paketet du nu förbereder, inte
den första version av paketet som saknade konffilen. Detta gäller på samma
sätt för alla andra åtgärder.

Som ett exempel, för en konffil som togs bort i version B<2.0-1> av ett
paket bör I<tidigareversion> sättas till B<2.0-1~>. Detta får konffilen att
tas bort även om användaren bygger om den tidigare versionen B<1.0-1> som
B<1.0-1local1>. Eller ett paket som bytt en sökväg från att vara en
symbolisk länk (skeppad i version B<1.0-1>) till en katalog (skeppad i
version B<2.0-1>), men bara utfört själva ändringen i utvecklarskripten i
version B<3.0-1>, bör sätta I<tidigareversion> till B<3.0-1~>.

=item I<paket>

Paketnamnet som äger sökvägsnamnet/-en. När paketet är ”Multi-Arch: same”
måste parametern innehålla arkitekturkvalificeraren, i andra fall bör den
B<inte> innehålla arkitekturkvalificeraren (eftersom det skulle hindra
korsgraderingar, eller byte från att vara arkitekturspecifikt till
B<all>-arkitektur eller vice veras). Om parametern är tom eller inte anges,
kommer miljövariablerna B<DPKG_MAINTSCRIPT_PACKAGE> och
B<DPKG_MAINTSCRIPT_ARCH> (som satta av B<dpkg> när utvecklarskripten körs)
att användas för att skapa ett arkitekturkvalificerat paketnamn.

=item B<-->

Alla parametrar till utvecklarskripten måste vidaresändas till programmen
efter B<-->.

=back

=head1 KONFFIL-RELATERADE ÅTGÄRDER

När ett paket uppgraderas kommer B<dpkg> inte att automatiskt ta bort en
konffil (en konfigurationsfil för vilken B<dpkg> ska behålla användarens
ändringar) om den inte finns i den nya versionen. Det finns två
grundläggande skäl till detta; den första är att konffilen kan ha tappats av
misstag och nästa version kan komma att återställa den, varpå användaren
inte vill tappa sina ändringar. Den andra är att för att göra det möjligt
för paket att gå över från en dpkg-hanterad konffil till en fil som hanteras
av paketets skript, vanligtvis genom ett verktyg som debconf eller ucf.

Det innebär att, om paketet menar att byta namn eller ta bort en
konfigurationsfil, så måste det göra så explicit, och då kan
B<dpkg-maintscript-helper> användas för att implementera en elegant
borttagning och flyttning av konffiler i paketscripten.

=head2 Ta bort en konffil

Observera: Det här kan i de flesta fall ersättas av flaggan
C<remove-on-upgrade> i F<DEBIAN/conffiles> (sedan dpkg 1.20.6), se
L<deb-conffiles(5)>.

Om en konffil helt tas bort bör den tas bort från disk, såvida inte
användaren har modifierat den. Om det finns lokala ändringar bör de
bibehållas. Om paketuppgraderingen avbryts bör inte konffilen som just blev
föråldrad försvinna.

Allt detta implementeras genom att lägga in följande skalkod i paketskripten
B<preinst>, B<postinst> och B<postrm>:

=over 

Z<>
 dpkg-maintscript-helper rm_conffile \
    I<konffil> I<tidigare-version> I<paket> -- "$@"

=back

I<konffil> är namnet på konffilen som ska tas bort.

Aktuell implementation: i B<preinst> kontrolleras om konffilen ändrades och
i så fall byts namnet på den till antingen I<konffil>B<.dpkg-remove> (om
inte modifierad) eller till I<konffil>B<.dpkg-backup> (om modifierad). I
B<postinst> byts namnet på den sistnämnda filen till I<konffil>B<.dpkg-bak>
och behålls som referens om den innehåller ändringar av användaren, medan
den tidigare kommer att tas bort. Om paketuppgraderingen avbryts kommer
B<postrm> att ominstallera den ursprungliga konffilen. Vid borttagning
kommer B<postrm> även att ta bort B<.dpkg-bak>-filen som behållits fram till
dess.

=head2 Byta namn på en konffil

Om en konffil flyttas från en plats till en annan måste du se till att du
flyttar med eventuella ändringar gjorda av användaren. Detta kan först verka
vara en enkel ändring av B<preinst>-skriptet, men det kommer leda till att
användaren ombeds att godkänna ändringar i konffilen för B<dpkg>, även om
denne inte är ansvarig för dem.

En elegant namnändring kan implementeras genom att lägga in följande skalkod
i paketskripten B<preinst>, B<postinst> och B<postrm>:

=over 

Z<>
 dpkg-maintscript-helper mv_conffile \
    I<gammal-konffil> I<ny-konffil> I<tidigare-version> I<paket> -- "$@"

=back

I<gammalkonffil> och I<nykonffil> är de gamla och nya namnen på konffilen
vars namn ska bytas.

Aktuell implementation: I B<preinst> kontrolleras om konffilen har ändrats,
om ja lämnas den kvar på plats, annars byts namnet på den till
I<gammalkonffil>B<.dpkg-remove>. Vid konfigurering tar B<postinst> bort
I<gammalkonffil>B<.dpkg-remove> och byter namn på I<gammalkonffil> till
I<nykonffil> om I<gammalkonffil> fortfarande finns. Vid avbruten
uppgradering eller installation byter B<postrm> tillbaka namnet från
I<gammalkonffil>B<.dpkg-remove> till I<gammalkonffil> om så behövs.

=head1 VÄXLING MELLAN SYMLÄNKAR OCH KATALOGER

Vid uppgradering av ett paket kommer B<dpkg> inte att automatiskt byta ut en
symbolisk länk mot en katalog, eller omvänt. Nedgraderingar stöds inte och
sökvägen kommer lämnas som den var.

=head2 Byta en symbolisk länk mot en katalog

Om en symbolisk länk byts mot en riktig katalog måste du se till att den
symboliska länken tas bort innan uppackningen. Detta kan först verka vara en
enkel ändring av B<preinst>-skriptet, men det kommer leda till vissa problem
om den lokale administratören har justerat den symboliska länken, eller om
paketet ska nedgraderas.

En elegant namnändring kan implementeras genom att lägga in följande skalkod
i paketskripten B<preinst>, B<postinst> och B<postrm>:

=over 

Z<>
 dpkg-maintscript-helper symlink_to_dir \
    I<sökvägsnamn> I<gammalt-mål> I<tidigare-version> I<paket> -- "$@"

=back

I<sökväg> är den absoluta sökvägen för den gamla symboliska länken (sökvägen
kommer vara en katalog när installationen är färdig) och I<gammalt-mål> är
målet på den tidigare symboliska länken i I<sökväg>. Den kan antingen vara
absolut eller relativ till katalogen som innehåller I<sökväg>.

Aktuell implementation: I B<preinst> kontrolleras om den symboliska länken
finns och pekar på I<gammalt-mål>, om inte lämnas den kvar, i annat fall
byts namnet ut mot I<sökväg>B<.dpkg-backup>. Vid konfigurering tar
B<postinst> bort I<sökväg>B<.dpkg-bakcup> om I<sökväg>B<.dpkg-backup>
fortfarande är en symbolisk länk. Vid avbruten uppgradering eller
installation byter B<postrm> tillbaka namnet från I<sökväg>B<.dpkg-bakcup>
till I<sökväg> om så behövs.

=head2 Byta en symbolisk länk mot en katalog

Om en riktig katalog byts mot en symbolisk länk måste du se till att
katalogen tas bort innan uppackningen. Detta kan först verka vara en enkel
ändring av B<preinst>-skriptet, men det kommer leda till vissa problem om
katalogen innehåller konffiler, sökvägar som ägs av andra paket, lokalt
skapade sökvägar, eller om paketet ska nedgraderas.

Ett elegant byte kan implementeras genom att lägga in följande skalkod i
paketskripten B<preinst>, B<postinst> och B<postrm>:

=over 

Z<>
 dpkg-maintscript-helper dir_to_symlink \
    I<sökvägsnamn> I<nytt-target> I<tidigare-version> I<paket> -- "$@"

=back

I<sökväg> är det absoluta namnet på den gamla katalogen (sökvägen kommer
vara en symbolisk länk när installationen är färdig) och I<nytt-mål> är
målet på den nya symboliska länken i I<sökväg>. Den kan antingen vara
absolut eller relativ till katalogen som innehåller I<sökväg>.

Aktuell implementation: I B<preinst> kontrolleras om katalogen finns, inte
innehåller konffiler, sökvägar som ägs av andra paket, eller lokalt skapade
sökvägar, om inte så kommer den lämnas kvar, annars byts namnet ut mot
I<sökväg>B<.dpkg-backup> och en tom samlingsplatskatalog skapas i I<sökväg>,
markerad med en fil så att dpkg kan hålla ordning på den. Vid konfigurering
slutför B<postinst> växlingen om I<sökväg>B<.dpkg-backup> fortfarande är en
katalog och I<sökväg> är samlingsplatskatalogen; den tar bort
märkningsfilen, flyttar nyligen skapade filer inuti samlingskatalogen till
målet för den symboliska länken I<nytt-mål>/, ersätter den nu tomma
samlingskatalogen I<sökväg> med en symbolisk länk till I<nytt-mål> och tar
bort I<sökväg>B<.dpkg-backup>. Vid avbruten uppgradering eller installation
byter B<postrm> tillbaka namnet från I<sökväg>B<.dpkg-backup> till I<sökväg>
om så behövs.

=head1 INTEGRERA I PAKET

När ett paketeringshjälpprogram används, kontrollera att det har direkt
integrering med B<dpkg-maintscript-helper>, något som kan göra ditt liv
enklare. Se till exempel B<dh_installdeb>(1).

Givet att B<dpkg-maintscript-helper> används i B<preinst> så innebär detta
villkorslöst att ett förhandsberoende (”pre-dependency”) krävs för att
försäkra att den nödvändiga versionen av B<dpkg> redan har packats upp. Den
version som krävs beror på vilket kommando som används, för B<rm_conffile>
och B<mv_conffile> är det 1.15.7.2, för B<symlink_to_dir> och
B<dir_to_symlnk> är det 1.17.14:

=over 

 Pre-Depends: dpkg (>= 1.17.14)

=back

Men i många fall är operationen som utförs av programmet inte kritiskt för
paketet, och istället för att använda ett förhandsberoende kan vi anropa
programmet endast om vi vet att det nödvändiga kommandot stöds av den nu
installerade B<dpkg>:

=over 

Z<>
 if dpkg-maintscript-helper supports I<kommando>; then
    dpkg-maintscript-helper I<kommando> ...
 fi

=back

Kommandot B<supports> returnerar 0 vid framgång, annars 1. Kommandot
B<supports> kontrollerar om miljövariablerna som sätts av dpkg och som krävs
av skriptet är närvarande, och kommer anse det som ett fel om
miljövariablerna inte är tillräckliga.

=head1 MILJÖVARIABLER

=over 

=item B<DPKG_ROOT>

Om satt kommer det användar som filsystemets rotkatalog.

=item B<DPKG_ADMINDIR>

Omm satt kommer det användas som B<dpkg>:s datakatalog.

=item B<DPKG_COLORS>

Väljer färgläge (sedan dpkg 1.19.1). För närvarande godtas följande värden:
B<auto> (förval), B<always> och B<never>.

=back

=head1 SE ÄVEN

B<dh_installdeb>(1).


=head1 ÖVERSÄTTNING

Peter Krefting och Daniel Nylander.