deb-src-control(5) | dpkg suite | deb-src-control(5) |
deb-src-control - Debians filformat för källkodspakets huvudstyrfil
debian/control
Varje Debiankällkodspaket innehåller huvudstyrfilen ”debian/control”, och dess deb822(5)-format är en övermängd av control-filen som medföljer Debianbinärpaket, se deb-control(5).
Filen innehåller åtminstone två stycken, avdelade med en tomrad. Det första stycket innehåller all generell information om källkodspaketet, medan de följande styckena beskriver exakt ett binärpaket. Varje stycke består av åtminstone ett fält. Ett fält inleds med ett fältnamn, till exempel Package eller Section (skiftlägesokänsligt), följt av ett kolon, fältinnehållet (skiftlägekänsligt om inte annat anges) och ett nyradstecken. Flerradiga fält är också tillåtna, men varje ytterligare rad som inte innehåller ett fältnamn, bör starta med minst ett blanksteg. Innehållet i flerradsfält slås normalt samman till en enda rad av verktygen (förutom i fallet fältet Description, se nedan). För att sätta in tomma rader i ett flerradsfält, skriver du en punkt efter blanksteget. Rader som börjar med ett ”#” tolkas som kommentarer.
Nyckelord består av namnrymd/fall. Delen namnrymd kan inte innehålla "/" eller blanksteg. Delen fall kan inte innehålla blanksteg. Dessutom måste bägge delarna i sin helhet bestå av skrivbara ASCII-tecken.
Varje verktyg/paket definierar en namnrymd med samma namn som sig själv och anger ett antal fall där (fake)root krävs. (Se "Implementation provided keywords" i rootless-builds.txt).
När fältet är satt till ett av impl-nyckelord kommer byggaren att exponera ett gränssnitt som används för att köra ett kommando under (fake)root. (Se "Gain Root API" i rootless-builds.txt.)
Gälten Section och Priority har vanligtvis en definierad uppsättning accepterade värden baserade på den specifika distributionens policy.
Syntaxen för fälten Build-Depends, Build-Depends-Arch och Build-Depends-Indep-fälten är en lista med grupper av alternativa paket. Varje grupp innehåller en lista med paket avdelade med ett vertikalstreck (rör), ”|”. Grupperna avdelas med kommatecken ”,”, och kan avslutas med ett släpande komma som tas bort när fälten genereras till deb-control(5) (sedan dpkg 1.10.14). Komma utläses som ”OCH”, och vertikalstrecken som ”ELLER”, där vertikalstrecken binder hårdare. Varje paketnamn kan eventuellt följas av en versionsnummerangivelse inom parenteser ”(” och ”)”, en arkitekturangivelse inom hakparenteser ”[” och ”]” samt en begränsningsformel som består av en eller flera listor med profilnamn inom vinkelparenteser ”<” och ”>”.
Syntaxen för fälten Build-Conflicts, Build-Conflicts-Arch och Build-Conflicts-Indep-fälten är en kommaseparerad lista med paketnamn, där komma utläses som ”OCH”, och där listan kan avslutas med ett släpande komma som tas bort när fälten genereras till deb-control(5) (sedan dpkg 1.10.14). Det är inte möjligt att ange alternativa paket med ”rör”. Varje paketnamn kan eventuellt följas av en versionsnummerangivelse inom parenteser, en arkitekturangivelse inom hakparenteser samt en begränsningsformel bestående av en eller flera listor med profilnamn inom vinkelparenteser.
Ett arkitekturkvalificeringsnamn kan vara ett existerande Debianarkitekturnamn (sedan dpkg 1.16.5), any (sedan dpkg 1.16.2) eller native (sedan dpkg 1.16.5). Om det utesluts är förvalet för fältet Build-Depends den aktuella värdarkitekturen, förvalet för Build-Conflicts är any. Ett existerande Debianarkitekturnamn motsvarar exakt den arkitekturen för det paketnamnet, any motsvarar valfri arkitektur för paketnamnet om paketet har markerats som Multi-Arch: allowed och native motsvarar nuvarande byggarkitektur om paketet inte har markerats som Multi-Arch: foreign.
Ett versionsnummer kan börja med ”>>”, vilket betyder att vilken som helst senare version matchar, där det är valfritt att ange Debianuppdateringen (avdelad med bindestreck). Tillåtna versionrelationer är ”>>” för större än, ”<<” för mindre än, ”>=” för större än eller lika med, ”<=” för mindre än eller lika med, och ”=” för lika med.
En arkitekturangivelse består av ett eller flera arkitekturnamn, avdelade med blanktecken. Varje namn kan föregås av ett utropstecken, vilket betyder ”ICKE”.
En begränsningsformel består av en eller flera begränsningslistor, avdelade med blanksteg. Varje begränsningslista skrivs inom vinkelparenteser. Poster i begränsningslistan är namn på byggprofiler, avdelade av blanksteg och kan föregås av ett utropstecken, vilket betyder ”ICKE”. En begränsningsformel representerar ett uttryck i disjunktiv normalform.
Observera att beroenden på paket i build-essential-uppsättningen kan utelämnas och att det är omöjligt att deklarera byggkonflikter mot dem. En lista över dessa paket finns i paketet build-essential.
Observera att fälten Priority, Section och Homepage även kan användas i de stycken som beskriver binärpaket för att överstyra de globala värdena för källkodspaketet.
Om ett stycke för ett binärpaket inte innehåller det här fältet betyder det implicit att det bygger i alla byggprofiler (inklusive ingen alls).
Med andra ord, om ett stycke för ett binärpaket är försett med ett icke-tomt Build-Profiles-fält kommer det binärpaketet byggas om, och endast om, villkoret, uttryckt i konjunktiv normalform, utvärderas till sant.
Det är tillåtet att lägga till ytterligare användardefinierade fält till styrfilen. Verktygen kommer ignorera dessa fält. Om du vill att fältet ska kopieras över till utdatafilerna, så som binärpaketen, måste du använda ett skräddarsytt namngivningsformat: fälten ska börja på X, följt av noll eller flera av tecknen SBC och ett bindestreck.
Observera att prefix på formen X[SBC]- tas bort när fälten kopieras över till utdatafilerna. Fältet XC-Approved-By kommer tas med som Approved-By i ”changes”-filen och inte tas med i styrfilerna för binär- och källkodspaketen.
Tänk på att dess användardefinierade fält använder den globala namnrymden, vilket en gång i framtiden kan komma att kollidera med officiellt erkända fält. För att undvika sådana potentiella situationer kan du använda prefixet Private- för dessa fält, som XB-Private-New-Field.
# Kommentar Source: dpkg Section: admin Priority: required Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org> # det här fältet kopieras till binär- och källkodspaketen XBS-Upstream-Release-Status: stable Homepage: https://wiki.debian.org/Teams/Dpkg Vcs-Browser: https://git.dpkg.org/cgit/dpkg/dpkg.git Vcs-Git: https://git.dpkg.org/git/dpkg/dpkg.git Standards-Version: 3.7.3 Build-Depends: pkg-config, debhelper (>= 4.1.81), libselinux1-dev (>= 1.28-4) [!linux-any] Package: dpkg-dev Section: utils Priority: optional Architecture: all # det här är ett skräddarsytt fält i binärpaketet XB-Mentoring-Contact: Raphael Hertzog <hertzog@debian.org> Depends: dpkg (>= 1.14.6), perl5, perl-modules, cpio (>= 2.4.2-2), bzip2, lzma, patch (>= 2.2-1), make, binutils, libtimedate-perl Recommends: gcc | c-compiler, build-essential Suggests: gnupg, debian-keyring Conflicts: dpkg-cross (<< 2.0.0), devscripts (<< 2.10.26) Replaces: manpages-pl (<= 20051117-1) Description: Debian package development tools This package provides the development tools (including dpkg-source) required to unpack, build and upload Debian source packages. . Most Debian source packages will require additional tools to build; for example, most packages need make and the C compiler gcc.
Peter Krefting och Daniel Nylander.
2023-09-13 | 1.20.13 |