1 files changed, 378 insertions, 0 deletions

diff --git a/man/sv/deb-src-symbols.pod b/man/sv/deb-src-symbols.pod
new file mode 100644
index 0000000..597c8a5
--- /dev/null
+++ b/man/sv/deb-src-symbols.pod
@@ -0,0 +1,378 @@
+
+        *****************************************************
+        *           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
+
+deb-src-symbols - Debians utökade mallfil för delade bibliotek
+
+=head1 SYNOPS
+
+B<debian/>I<paket>B<.symbols.>I<ark>, B<debian/symbols.>I<ark>,
+B<debian/>I<paket>B<.symbols>, B<debian/symbols>
+
+=head1 BESKRIVNING
+
+Symbolfilmallar medföljer Debiankällkodspaket och dess format är en
+övermängd av symbols-filen som sänds med Debianbinärpaket, se
+L<deb-symbols(5)>.
+
+=head2 Kommentarer
+
+Kommentarer stöds i symbolmallfilerna. Alla rader med ”#” som första tecken
+är kommentarer, såvida inte det börjar med ”#include” (se stycket B<Använda
+inkluderingar>). Rader som börjar med ”#MISSING:” är speciella kommentarer
+som dokumenterar symboler som har försvunnit.
+
+=head2 Använda #PACKAGE#-substituering
+
+I några sällsynta fall skiljer sig namnet på biblioteket mellan
+arkitekturer. För att undvika att hårdkoda namnet på paketet i symbolfilen
+kan du använda markören I<#PACKAGE#>. Den ersätts av det faktiska
+paketnamnet när symbolfilen installeras. Till skillnad från
+I<#MINVER#>-markören kommer I<#PACKAGE#> aldrig att dyka upp i en symbolfil
+i ett binärpaket.
+
+=head2 Använda symboltaggar
+
+Symboltaggning är nyttigt för att markera symboler som är speciella på något
+sätt. Alla symboler kan ha ett godtyckligt antal taggar associerade med
+sig. Medan alla taggar tolkas och lagras är det bara ett par av dem som
+förstås av B<dpkg-gensymbols> och som utlöser specialhantering av
+symbolerna. Se undersymbolen B<Standardsymboltaggar> för mer information om
+dessa taggar.
+
+Taggarna anges precis före symbolnamnet (inga blanksteg tillåts mellan). Den
+börjar alltid med en vänsterparentes B<(>, slutar med en högerparentes B<)>,
+och måste innehålla minst en tagg. Ytterligare taggar avdelas med tecknet
+B<|>. En tagg kan ha ett värde, vilket separeras från taggnamnet med tecknet
+B<=>. Taggnamn och värden kan vara godtyckliga strängar, förutom att de inte
+kan innehålla de speciella tecknen B<)> B<|> B<=>. Symbolnamn som följer en
+taggangivelse kan, om så önskas, citeras med antingen B<'> eller B<"> för
+att tillåta blanksteg. Om inga taggar anges för symbolen tolkas dock
+citattecken som en del av symbolnamnet, vilket fortsätter till det första
+blanksteget.
+
+  (tag1=jag är markerad|taggnamn med blanksteg)"taggad citerad symbol"@Base 1.0
+  (optional)taggad_ociterad_symbol@Base 1.0 1
+  otaggad_symbol@Base 1.0
+
+Den första symbolen i exemplet är heter I<taggad citerad symbol> och har två
+taggar: I<tag1> med värdet I<jag är markerad> och I<taggnamn med blanksteg>
+som inte har något värde. Den andra symbolen heter I<taggad_ociterad_symbol>
+och är bara taggad med taggen som heter I<optional>. Den sista symbolen är
+ett exempel på en normal, otaggad symbol.
+
+Eftersom symboltaggar er en utökning av formatet i I<deb-symbols(5)> kan de
+bara användas i symbolfiler i källkodspaket (dessa filer är att anse som
+mallar som används för att bygga symbolfilerna som finns i
+binärpaketen). När B<dpkg-gensymbols> anropas utan flaggan B<-t> kommer det
+att mata ut symbolfiler kompatibla med B<deb-symbols>(5)-formatet: det
+hanterar symboler helt beroende på vad som beskrivs av standardtaggarna och
+tar bort alla taggar från utdata. I mall-läge (B<-t>) kommer däremot alla
+symboler och deras taggar (både standard och okända) att behållas i utdata
+och skrivas i sin originalform så som de lästes in.
+
+=head2 Standardsymboltaggar
+
+=over 
+
+=item B<optional>
+
+En symbol markerad som valfri (optional) kan försvinna från bibliotektet när
+som helst och kommer aldrig göra så att B<dpkg-gensymbols>
+misslyckas. Försvunna symboler kommer dock fortfarande visas som saknade
+(MISSING) i differensen för varje ny paketversion. Detta beteende fungerar
+som en påminnelse för de paketansvariga om att symbolen måste tas bort från
+symbolfilen eller läggas tillbaka till biblioteket. När en valfri symbol som
+tidigare markerats som saknad (MISSING) plötsligt dyker upp igen i en senare
+version kommer den att uppgraderas tillbaka till befintligstatus
+(”existing”) med den minsta tillgängliga versionen oförändrad.
+
+Taggen är användbar för symboler som är privata och vars försvinnande inte
+gör att ABI:et går sönder. De flesta C++-mallinstansieringar faller till
+exempel in under denna kategori. Som andra taggar kan den här även ha ett
+godtyckligt värde: det kan användas för att indikera varför symbolen är att
+anse som valfri.
+
+=item B<arch=>I<arkitekturlista>
+
+=item B<arch-bits=>I<arkitekturlista>
+
+=item B<arch-endian=>I<arkitektur-byteordning>
+
+Dessaa taggar gör det möjligt att begränsa vilken uppsättning arkitekturer
+symbolen är tänkt att finnas för. Taggarna B<arch-bits> och B<arch-endian>
+stöds sedan dpkg 1.18.0. När symbollistan uppdateras med symboler som
+upptäcks i biblioteket behandlas alla arkitekturspecifika symboler som inte
+gäller den aktuella värdarkitekturen som om de inte fanns. Om en
+arkitekturspecifik symbol som motsvarar den aktuella värdarkitekturen inte
+existerar i biblioteket gäller de vanliga reglerna för saknade symboler, och
+kan få B<dpkg-gensymbols> att misslyckas. Å andra sidan, om en
+arkitekturspecifik symbol hittas där den inte var menad att finnas (då den
+aktuella värdarkitekturen inte är listad i taggen eller inte motsvarar
+byteordningen eller antal bitar), görs den arkitekturneutral (dvs. taggarna
+arch, arch-bits och arch-endgian tas bort och symbolen kommer finnas med i
+differensen på grund av denna ändring), men den anses inte som ny.
+
+I det vanliga icke-mall-läget skrivs endast de arkitekturspecifika symboler
+som motsvarar den aktuella värdarkitekturen till symbolfilen. Å andra sidan
+skrivs alla arkitekturspecifika symboler (inklusive de från andra
+arkitekturer) till symbolfilen i mall-läget.
+
+Formatet på I<arkitekturlista> är detsamma som det som används i
+B<Build-Depends>-fältet i I<debian/control> (bortsett från de omslutande
+hakparenteserna []). Den första symbolen från listan nedan, till exempel,
+kommer endast att tas med på arkitekturerna alpha, valfri-amd64, ia64, den
+andra bara på linux-arkitekturer medan den tredje tas med överallt förutom
+på armel.
+
+  (arch=alpha any-amd64 ia64)64bitarsspecifik_symbol@Base 1.0
+  (arch=linux-any)linuxspecifik_symbol@Base 1.0
+  (arch=!armel)symbol_armel_inte_har@Base 1.0
+I<architecture-bits> är antingen B<32> eller B<64>.
+
+  (arch-bits=32)32bitarsspecifik_symbol@Base 1.0
+  (arch-bits=64)64bitarsspecifik_symbol@Base 1.0
+
+I<architecture-byteordning> är antingen B<little> eller B<big>.
+
+  (arch-endian=little)little_endianspecifik_symbol@Base 1.0
+  (arch-endian=big)big_endianspecifik_symbol@Base 1.0
+
+Flera begränsningar kan kedjas samman
+
+  (arch-bits=32|arch-endian=little)32bitars_le_symbol@Base 1.0
+
+=item B<allow-internal>
+
+dpkg-gensymbols har en intern svartlista över symboler som inte ska
+förekomma i symbolfiler eftersom de oftast bara är sidoeffekter från
+implementationsdetaljer i verktygskedjan (sedan dpkg 1.20.1). Om du, av
+någon orsak, verkligen vill att en av dessa symboler ska tas med i
+symbolfilen måste du tagga symbolen med B<allow-internal>. Det kan vara
+nödvändigt för lågnivå-verktygskedjebibliotek som ”libgcc”.
+
+=item B<ignore-blacklist>
+
+Ett alias för B<allow-internal> som avråds från (sedan dpkg 1.20.1, stöds
+sedan dpkg 1.15.3).
+
+=item B<c++>
+
+Betecknar I<c++>-symbolmönster. Se stycket B<Använda symbolmönster> nedan.
+
+=item B<symver>
+
+Anger I<symver> (symbolversion)-symbolmönstret. Se stycket B<Använda
+symbolmönster> nedan.
+
+=item B<regex>
+
+Anger I<regex>-symbolmönstret. Se stycket I<Använda symbolmönster> nedan.
+
+=back
+
+=head2 Använda symbolmönster
+
+Till skillnad från vanliga symbolspecifikationer kan ett mönster täcka flera
+faktiska symboler från biblioteket. B<dpkg-gensymbols> kommer försöka matcha
+varje mönster mot varje faktisk symbol som I<inte> har en motsvarande
+specifik symbol definierad i symbolfilen. Så fort det första mönster som
+motsvarar symbolen hittas kommer alla dess taggar och egenskaper att
+användas som en basspecifikation för symbolen. Om inget mönster motsvarar
+symbolen kommer den att tolkas som ny.
+
+Ett mönster anses som tappat om det inte motsvarar några symboler i
+biblioteket. Som standard kommer detta få B<dpkg-genchanges> att misslyckas
+om B<-c1> eller högre anges. Om ett sådant misslyckande inte är önskvärt kan
+mönstret dock märkas med taggen I<optional>. Om mönstret då inte motsvarar
+någonting kommer det bara dyka upp i differensen som saknas
+(MISSING). Mönstret kan dessutom, precis som andra symboler, begränsas till
+specifika arkitekturer med hjälp av I<arch>-taggen. Se stycket
+B<Standardsymboltaggar> ovan för mer information.
+
+Mönster är en utökning av B<deb-symbols(5)>-formatet och är därför endast
+tillåtna i symbolfilmallar. Syntax för angivelse av mönster skiljer sig inte
+från den för en specifik symbol. Symbolnamnsdelen av specifikationen
+fungerar dock som ett uttryck som ska jämföras mot I<namn@version> för den
+faktiska symbolen. För att skilja mellan olika sorters mönster, taggas
+mönster normalt med en speciell tagg.
+
+För närvarande stöder B<dpkg-gensymbols> tre grundläggande mönstertyper:
+
+=over 
+
+=item B<c++>
+
+Detta mönster anges med taggen I<c++>. Den matchar enbart C++-symboler med
+deras avmanglade symbolnamn (som det skrivs ut av
+B<c++filt>(1)-verktyget). Det här mönstret är väldigt nyttigt för att matcha
+symboler vars manglade namn kan skilja sig mellan olika arkitekturer, medan
+deras avmanglade namn är desamma. En grupp dylika symboler är
+I<icke-virtuella ”thunks”> som har arkitekturspecifika offsetvärden inbyggda
+i sina manglade namn. En vanlig instans av detta fall är en virtuell
+destruktör som under diamantarv behöver en icke-virtuell
+”thunk”-symbol. Även om till exempel ZThn8_N3NSB6ClassDD1Ev@Base på
+32-bitarsarkitekturer troligtvis är _ZThn16_N3NSB6ClassDD1Ev@Base
+på64-bitarsarkitekturer, så kan de matchas med ett enda I<c++>-mönster:
+
+ libdummy.so.1 libdummy1 #MINVER#
+  [...]
+  (c++)"non-virtual thunk to NSB::ClassD::~ClassD()@Base" 1.0
+  [...]
+Det avmanglade namnet ovan kan hämtas genom att utföra följande kommando:
+
+  $ echo '_ZThn8_N3NSB6ClassDD1Ev@Base' | c++filt
+
+Observera att även om det manglade namnet per definition är unikt i
+biblioteket gäller inte detta för avmanglade namn. Flera distinkta verkliga
+symboler kan ha samma avmanglade namn. Det gäller till exempel för
+icke-virtuella ”thunk”-symboler i konfigurationer med komplexa arv eller för
+de flesta konstruktörer och destruktörer (eftersom g++ normalt genererar två
+symboler för dem). Eftersom dessa kollisioner sker på ABI-nivån bör de dock
+inte sänka kvaliteten på symbolfilen.
+
+=item B<symver>
+
+Detta mönster anges med taggen I<symver>. Välunderhållna bibliotek har
+versionshanterade symboler där varje version motsvarar uppströmsversionen
+där symbolen lades till. Om det är fallet kan du använda ett
+I<symver>-möster för att matcha alla symboler som matchar den specifika
+versionen. Till exempel:
+
+ libc.so.6 libc6 #MINVER#
+  (symver)GLIBC_2.0 2.0
+  [...]
+  (symver)GLIBC_2.7 2.7
+  access@GLIBC_2.0 2.2
+Alla symboler associerade med versionerna GLIBC_2.0 och GLIBC_2.7 kommer
+leda till den minimal version 2.0 respektive 2.7, med undantag av symbolen
+access@GLIBC_2.0. Den sistnämnda kommer leda till ett minsta beroende på
+libc6 version 2.2 trots att den motsvarar mönstret
+"(symver)GLIBC_2.0"-mönstret, eftersom specifika symboler gäller före
+mönster.
+
+Observera att även om den gamla sortens jokerteckenmönster (anges med
+"*@version" i symbolnamnfältet) fortfarande stöds så rekommenderas de inte
+längre i och med den nya sortens syntax "(symver|optional)version". Till
+exempel bör "*@GLIBC_2.0 2.0" skrivas som "(symver|optional)GLIBC_2.0 2.0"
+om samma beteende behövs.
+
+=item B<regex>
+
+Mönster med reguljära uttryck anges med taggen I<regex>. De matchar med det
+reguljära uttrycket på perl-form som anges i symbolnamnsfältet. Ett
+reguljärt uttryck matchar som det står, glöm därför inte att inleda det med
+tecknet I<^>, annars kommer det matcha godtycklig del av den verkliga
+symbolens I<namn@version>-sträng. Till exempel:
+
+ libdummy.so.1 libdummy1 #MINVER#
+  (regex)"^mystack_.*@Base$" 1.0
+  (regex|optional)"private" 1.0
+Symboler som "mystack_new@Base", "mystack_push@Base", "mystack_pop@Base"
+osv. kommer att träffas av det första mönstret medan t.ex
+"ng_mystack_new@Base" inte gör det. Det andra mönstret motsvarar alla
+symbolen som innehåller strängen "private" i sina namn och träffar kommer
+att ärva I<optional>-taggen från mönstret.
+
+=back
+
+Grundläggande mönster som anges ovan kan kombineras där det är vettigt. I så
+fall behandlas de i den ordning taggarna anges. Till exempel kommer både:
+
+  (c++|regex)"^NSA::ClassA::Private::privmethod\d\(int\)@Base" 1.0
+  (regex|c++)N3NSA6ClassA7Private11privmethod\dEi@Base 1.0
+att träffa symbolerna "_ZN3NSA6ClassA7Private11privmethod1Ei@Base" och
+"_ZN3NSA6ClassA7Private11privmethod2Ei@Base". När det första mönstret
+jämförs avmanglas först symbolen som en C++-symbol, varefter det avmanglade
+namnet jämförs med det reguljära uttrycket. När det andra mönstret jämförs,
+å andra sidan, jämförs det reguljära uttrycket mot det råa symbolnamnet,
+varefter symbolen testas för att se om det är av C++-typ genom att försöka
+avmangla det. Om ett grundläggande mönster misslyckas kommer hela uttrycket
+att misslyckas. Därför kommer, till exempel
+"__N3NSA6ClassA7Private11privmethod\dEi@Base" inte att träffas av något av
+mönstrena eftersom det inte är en giltig C++-symbol.
+
+I allmänhet delas alla mönster in i två grupper. alias (grundläggande I<c++>
+och I<symver>) och generella mönster (I<regex>, samtliga kombinationer av
+multipla grundläggande mönster). Det går snabbt att träffa grundläggande
+aliasbaserade mönster (O(1)) medan generella mönster är O(N) (N - antal
+generella mönster) för varje symbol. Det rekommenderas därför inte att
+använda för många generella mönster.
+
+När flera mönster träffar samma verkliga symbol föredras alias (först
+I<c++>, sedan I<symver>) framför generella mönster. Generella mönster
+träffas i den ordning de upptäcktes i symbolfilmallen fram till den första
+lyckade träffen. Observera dock att manuell omsortering av poster i
+mallfilen inte rekommenderas då B<dpkg-gensymbols> genererar differensfiler
+baserad på den alfanumeriska sorteringsordningen av dess namn.
+
+=head2 Använda inkluderingar
+
+När uppsättningen av exporterade symboler skiljer sig mellan arkitekturer
+kan det vara ineffektivt att använda en enda symbolfil. I dessa fall kan ett
+inkluderingsdirektiv vara nyttigt på flera sätt:
+
+=over 
+
+=item *
+
+Du kan faktorisera de gemensamma delarna i en extern fil och inkludera den
+filen i din I<paket>.symbols.I<arkitektur>-fil genom att använda ett
+inkluderingsdirektiv som detta:
+
+ #include "I<paket>.symbols.common"
+
+=item *
+
+Inkluderingsdirektivet kan även taggas som alla andra symboler:
+
+ (tagg|...|taggN)#include "fil-att-inkludera"
+
+Alla symboler som inkluderas från I<fil-att-inkludera> kommer att anses som
+standard vara taggade med I<tagg> ... I<taggN>. Du kan använda denna
+funktion för att skapa en gemensam I<paket>.symbols-fil som inkluderar
+arkitekturspecifika filer:
+
+  gemensam_symbol1@Base 1.0
+ (arch=amd64 ia64 alpha)#include "paket.symbols.64bit"
+ (arch=!amd64 !ia64 !alpha)#include "paket.symbols.32bit"
+  gemensam_symbol2@Base 1.0
+
+=back
+
+Symbolfilerna läses radvis, och inkluderingsdirektiv utförs så fort de
+upptäcks. Det betyder att innehållet i den inkluderade filen kan överstyra
+allt innehåll som förekom före inkluderingsdirektivet och att innehåll efter
+direktivet kan överstyra allt från den inkluderade filen. Alla symboler
+(även andra #include-direktiv) i den inkluderade filen kan ange ytterligare
+taggar eller överstyra värden för de ärvda taggarna i sin
+taggspecifikation. Det finns dock inte något sätt för en symbol att ta bort
+någon av sina ärvda taggar.
+
+En inkluderad fil kan repetera huvudraden som innehåller SONAME:t för
+biblioteket. I så fall överstyr den en eventuell huvudrad som lästs in
+tidigare. Det är vanligtvis dock bäst att undvika att duplicera
+huvudrader. Ett sätt att göra det är som följer:
+
+ #include "libnågonting1.symbols.common"
+  arkitekturspecifik_symbol@Base 1.0
+=head1 SE ÄVEN
+
+B<deb-symbols>(5), B<dpkg-shlibdeps>(1), B<dpkg-gensymbols>(1).
+
+
+=head1 ÖVERSÄTTNING
+
+Peter Krefting och Daniel Nylander.