diff options
author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-27 09:40:31 +0000 |
---|---|---|
committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-27 09:40:31 +0000 |
commit | b86570f63e533abcbcb97c2572e0e5732a96307b (patch) | |
tree | cabc83be691530ae685c45a8bc7620ccc0e1ebdf /man/sv/dpkg-maintscript-helper.pod | |
parent | Initial commit. (diff) | |
download | dpkg-b86570f63e533abcbcb97c2572e0e5732a96307b.tar.xz dpkg-b86570f63e533abcbcb97c2572e0e5732a96307b.zip |
Adding upstream version 1.20.13.upstream/1.20.13upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'man/sv/dpkg-maintscript-helper.pod')
-rw-r--r-- | man/sv/dpkg-maintscript-helper.pod | 319 |
1 files changed, 319 insertions, 0 deletions
diff --git a/man/sv/dpkg-maintscript-helper.pod b/man/sv/dpkg-maintscript-helper.pod new file mode 100644 index 0000000..d54e3e1 --- /dev/null +++ b/man/sv/dpkg-maintscript-helper.pod @@ -0,0 +1,319 @@ + + ***************************************************** + * 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. |