deb-filen är ett arkiv i formatet ar, som innehåller installationsfiler program, information om programmet, samt skript (kommandofiler) som körs före och efter installation och borttagning av programmet (närvaron av skript är valfritt - de kanske inte ingår i paketet).
Formatet på deb-filen beskrivs i man-sidorna (man-sidor) deb(5) - den här hjälpen visas om du skriver kommandot man deb i terminalen. Det finns också många sidor på Internet som innehåller denna information - skriv bara deb(5) i sökfältet för att hitta dem. Denna handbok ingår inte här eftersom den officiella Debians utvecklarmanual, paketformatreferens (som, när detta skrivs, finns på http://www.debian.org/doc/manuals/debian-faq/ch- pkg_basics.en.html) står det skrivet att formatet på paket kan ändras, och därför rekommenderas att använda verktyget dpkg-deb för att arbeta med dem. Du kan få hjälp med verktyget dpkg-deb genom att skriva man dpkg-deb i en terminal.
GUI-deb-programmets arbete är just att skapa en katalog som innehåller nödvändiga data, och köra programmet dpkg-deb, specificera denna katalog och andra nödvändiga parametrar.
Den korrekta katalogen som behövs för att dpkg-deb ska skapa ett installationspaket måste först och främst innehålla en "DEBIAN" underkatalog. Denna katalog ska innehålla all data som inte kopieras till systemet, utan används direkt av program för att arbeta med paket - information om paketet, skript som körs före och efter installationen, etc. Alla filer som finns i DEBIAN-katalogen kommer inte att hamna i filsystemet på den dator som paketet är installerat på när paketet installeras.
Utanför "DEBIAN"-katalogen finns de filer som kommer att kopieras till filsystemet på den dator där paketet kommer att installeras. Filerna måste finnas i de kataloger som de kommer att placeras i när paketet installeras. Det vill säga, inuti katalogen som skapats för dpkg-deb ska en kopia av de delar av filsystemet vi behöver skapas - som om den här katalogen vore dess rot ("/"). Det vill säga, till exempel, om namnet på katalogen på grundval av vilken paketet kommer att skapas är "~/TMP_DEBS/MyProgram", och det är nödvändigt att när du installerar i filsystem filen "MyProgram.png" skrevs till "/usr/share/pixmaps"-katalogen - du måste skapa "usr"-katalogen i "~/TMP_DEBS/MyProgram"-katalogen, i den - "share"-katalogen, inuti "share" - "pixmaps"-katalogen ", och redan i "pixmaps"-katalogen placera filen "MyProgram.png". Som ett resultat kommer den fullständiga sökvägen till filen att vara "~/TMP_DEBS/MyProgram/usr/share/pixmaps/MyProgram.png". När du skapar ett paket kommer en del av katalogen "~/TMP_DEBS/MyProgram" att trunkeras, och under installationen kommer filen "MyProgram.png" bara att komma till den önskade adressen "/usr/share/pixmaps". Därför måste de nödvändiga katalogerna skapas för varje fil.
Efter att ha skapat katalogen återstår bara att köra dpkg-deb och skicka de nödvändiga parametrarna. De viktigaste dpkg-deb-alternativen för att bygga paket beskrivs i avsnittet "Kommandoradsalternativ för dpkg-deb-verktyget" . Om det inte finns några fel i kontrollfilen skapas installationspaketet.
Jag beskrev att bygga programmet från källan, samt skapa ett enkelt deb-paket. Den här gången vill jag uppehålla mig mer i detalj vid deras skapelse. Den här guiden gör inte anspråk på att vara en guide för utvecklare eller underhållare, så i slutet kommer jag att ge länkar till detaljerade guider från utvecklare Debian.
Det finns en hel del sätt att skapa ett deb-paket. Jag kommer inte att beskriva de stora byggsystem som används på byggservrar här, eftersom de flesta inte behöver det. Jag kommer att beskriva två av de mest enkla sätt skapa ditt paket. Först och främst måste vi installera några verktyg för arbete:
sudo apt-get install build-essential git automake devscripts gör libtool fakeroot automake autotools-dev
Därefter måste du skapa en digital nyckel. Detta steg är valfritt, men om du planerar att omdistribuera dina paket skulle det vara extremt klokt att signera dem med din nyckel. Detta gör att användaren som laddade ner ditt paket kan verifiera att det var du som skapade det. För att skapa en nyckel kan du använda grafiska verktyg ( sjöhäst, kgpg) eller i terminalen:
DEBEMAIL="din e-post som du angav när du skapade nyckeln"
DEBFULLNAME="Ditt namn (eller alias)"
exportera DEBEMAIL DEBFULLNAME
Detta kommer automatiskt att lägga till din digital signatur vid signering av paket. Därefter behöver vi ett arkiv med källkod. Jag kommer att utföra ett enkelt exempel, eftersom, beroende på programmets komplexitet, ytterligare konfiguration krävs (skapande av skript efter installation, monteringsregler, etc.). Anta att vi har ett arkiv med programmets källkod "mitt program" - myprogramm_1.0.tar.gz. Packa upp den till din hemkatalog (eller var du föredrar det). Observera: katalogen efter uppackning måste ha namnet myprogramm-1.0. Namn följt av ett bindestreck - versionsnummer. Öppna nu en terminal och kör:
cd ~/myprogramm-1.0
dh_make --createorig
Vi flyttade in i källkatalogen och skapade ett arkiv med den och en grundläggande debianisering. Efter det andra kommandot kommer ett meddelande att visas där du måste välja pakettyp: s (enkel, enkel), m (flera, flera paket), l (bibliotek, bibliotek), k (kärnmodul, kärnmodul). I vårt fall är detta s. Nu måste vi fixa lite. Gå till katalogen /myprogramm-1.0/debian och öppna filen kontrollera i vilken textredigerare som helst. Detta är huvudfilen för att bygga paketet. Den innehåller all grundläggande information. Det ser ut ungefär så här:
Källa: mitt program
Avsnitt: admin
Prioritet: valfritt
Underhållare: Aleksey Samoilov
Build-Depends: debhelper (>= 5)
Standard-version: 3.9.6
Hemsida: http://www.example.com
Paket: mitt program
Arkitektur: allt
Depends: $(shlib:Depends), $(misc:Depends)
Avsnitt: admin
Prioritet: valfritt
Beskrivning: Mitt nya program
Mitt program är ett enkelt exempel för att bygga ditt eget deb-paket
Låt oss gå i ordning. Det första avsnittet innehåller namnet på källpaketet. Därefter, mjukvaruavsnittet (i det här fallet administration). Sedan prioriteten (valfritt), namnet på underhållaren och hans e-post (dvs din), byggberoenden (paket som behövs för att bygga), versionen av standarden (på det här ögonblicket 3.9.7), följt av namnet på paketet efter konstruktionen, arkitekturen för vilken det är byggt (alla betyder alla arkitekturer som stöds), mjukvaruavsnitt, prioritet, kort beskrivning Och Full beskrivning. Eftersom vårt exempel är enkelt räcker detta för att komma igång. Du kan också öppna filen upphovsrätt och ange ditt namn och din e-postadress där. I fil ändringslogg innehåller en lista över ändringar för varje version av denna programvara. Eftersom detta är den första versionen måste du ange att detta är första utgåvan och även stänga en viss bugg (avsaknad av detta paket i förvaret). Buggnumret kan skrivas från bulldozern. Om du bygger om ett paket, ändra först dess version med kommandot dch-i Filer i debiankatalogen med tillägg .exär exempel. När du bygger mer komplexa paket behöver du dessa ytterligare filer. Dessa är till exempel efterinstallationsskript ( postinst), en fil som söker efter ny version tarball med källkod ( Kolla på) och så vidare. Fil reglerär en makefile, reglerna för att montera paketet. För enkla program du kan inte ändra det i andra fall - du måste redigera det, ange monteringsparametrarna eller installera ikoner. Många saker.
Nu när du har fyllt i kontrollfilen kan du börja bygga. För att göra detta, kör kommandot i katalogen med källkoden bygga om. Systemet kommer att konfigurera, kompilera programmet, packa det i ett paket, leta efter vanliga fel under debianiseringen och be dig ange lösenordet för din nyckel två gånger (om du inte skapade det kommer ingenting att hända). Nu i katalogen en nivå högre (i vårt fall i hemkatalogen), kommer du att se flera filer, bland annat deb-paketet du letar efter. Nu kan den installeras med kommandot sudo dpkg -i myprogramm-1.0-1.deb eller i Gdebis grafiska hanterare.
Så här kan du sätta ihop ett enkelt paket. Men vad händer om du inte vill skräpa systemet med en massa byggberoenden? Dessutom, när man bygger vissa paket, kan vissa modifierade filer användas. Till exempel nyare versioner av bibliotek, om du uppdaterade systemet från backports, eller olika ändringar i konfigurationer. På liknande fall du kan använda virtuell maskin, container, eller använd ett specialverktyg som kallas pbulder. pbyggareär ett verktyg för att skapa en ren miljö som bara innehåller det som behövs för bygget. Systemet blir inte igensatt. skräpfiler, och sammansättningen av programmet sker i laboratoriet. Installera:
sudo apt installera pbuilder
Jag kommer att ge ett exempel på min konfiguration, med vilken du kan bygga paket inte bara för olika Debian-utgåvor, utan också för Ubuntu.
sudo nano /etc/pbuilderrc
Klistra in följande innehåll:
STABLE_CODENAME="stabil"
OLDSTABLE_CODENAME="oldstable"
DEBIAN_SUITES=($UNSTABLE_CODENAME, $TESTING_CODENAME, $STABLE_CODENAME $STABLE_BACKPORTS_SUITE $OLDSTABLE_CODENAME
"sid" "stretch" "jessie" "wheezy")
UBUNTU_SUITES=("precis" "pålitlig" "xenial")
UBUNTU_MIRROR="mirror.yandex.ru"
DEBIAN_MIRROR="mirror.yandex.ru"
: $(DIST:="$(lsb_release --short --codename)")
: $(ARCH:="$(dpkg --print-architecture)")
NAME="$DIST"
if [ -n "$(ARCH)" ]; sedan
NAME="$NAME-$ARCH"
# nästa rad behövs för att bygga för olika arkitekturer
DEBOOTSTRAPOPTS=("--arch" "$ARCH" "$(DEBOOTSTRAPOPTS[@])")
fi
BASETGZ="/home/sunderland93/pbuilder/$NAME-base.tgz"
DISTRIBUTION="$DIST"
BUILDRESULT="/home/sunderland93/pbuilder/$DIST/result/"
APTCACHE="/home/sunderland93/pbuilder/$NAME/aptcache/"
BUILDPLACE="/home/sunderland93/pbuilder/build/"
if $(echo $(DEBIAN_SUITES[@]) | grep -q $DIST); sedan
MIRRORSITE="http://$DEBIAN_MIRROR/debian/"
COMPONENTS="huvudbidrag ej gratis"
elif $(echo $(UBUNTU_SUITES[@]) | grep -q $DIST); sedan
MIRRORSITE="http://$UBUNTU_MIRROR/ubuntu/"
COMPONENTS="main restricted universe multiverse"
annan
echo "Okänd distribution: @DIST"
utgång 1
fi
exportera DPKG_GENSYMBOLS_CHECK_LEVEL=4
USE_PDEBUILD_INTERNAL=ja
Ersätt sunderland93 med ditt systemnamn. Således kommer vi att kunna bygga paket för Debian 7, 8, testande och instabila, såväl som för Ubuntu 12.04, 14.04 och 16.04. Beroenden som laddas ner för montering kommer att finnas i pbuilder/distributionsnamn/aptcache. Detta är förresten väldigt användbart - vi kommer att ha ett basarkiv som inte kommer att vara igensatt med vänsterhänta beroenden och väger flera gigabyte. Och miljön kommer att förberedas individuellt för varje program. Det är möjligt att sy in dessa beroenden i basarkivet, men jag rekommenderar inte att göra detta. Låt oss nu skapa ett basarkiv som innehåller en ren byggmiljö. Låt oss ta Debian 8 64-bitars som ett exempel:
sudo DIST=jessie ARCH=amd64 pbuilder --skapa
Processen att skapa arkiv börjar. När det är klart kan du börja bygga programmet. För att göra detta, öppna en terminal, gå till katalogen med källkoden och kör:
sudo DIST=jessieARCH=amd64 pdebuild
Och vi väntar. De nedladdade paketen kommer att cachelagras, och nästa gång kommer jag inte att ladda ner. Efter byggandet kommer det färdiga deb-paketet att dyka upp i katalogen pbuilder/jessie/result. Det är allt.
Idag ska jag berätta om ett abstrakt exempel hur Höger skapa *.deb-paket för Ubuntu/Debian. Vi kommer att göra paketet binärt. Paket som kompilerar binärer från källor beaktas inte här: efter att ha bemästrat kunskapen som presenteras nedan, i framtiden, med hjälp av färdiga exempel, kan du förstå essensen och agera analogt :)
Det blir inget onödigt krångel "manuellt" i artikeln: paketformatet har utvecklats till en ganska enkel, och viktigast av allt, logisk struktur, och allt görs bokstavligen på knäet, med hjälp av ett par specialiserade verktyg.
Som en bonus kommer det i slutet av artikeln att finnas ett exempel på hur du snabbt kan skapa ditt eget lokala förråd: genom att installera paket från förvaret kan du automatiskt spåra beroenden, och såklart! - installera alla en konsolkommandot på flera maskiner :)
För dem som inte vill gå in i det kraftfulla installationssystemet för programvara i Linux rekommenderar jag att besöka programmet CheckInstall: det skapar automatiskt ett deb-paket från kommandot "make install";) Och vi, tillsammans med de nyfikna -
| Attribut | Beskrivning | Exempel |
|---|---|---|
| - grundläggande - | ||
| paket: | Paketnamn: - endast latin, siffror och bindestreck. Namn som användes under installationen: apt-get install |
Paket: supersh |
| version: | Versionen av paketet (och programmet inuti). Används för att avgöra om den ska uppdateras. Formatet som antas är:<версия_программы>-<версия_пакета> . jag rekomenderar Alltid ange versionen av paketet: när du ändrar paketets struktur ökar antalet med en. Giltiga tecken är ganska gratis: du kan använda datum och bokstäver. Se exempel idag i ditt arkiv :) |
Version: 1.0-1 Version: 2009.12.12-1 |
| Ger | Programnamnet (eventuellt virtuellt) som registreras i systemet som ett resultat av installationen av detta paket. Används sällan: oftast om du behöver ändra paketnamnet, eller om mer än ett paket erbjuder samma funktionalitet. Till exempel erbjuder Apache- och nginx-paketen httpd-demon-kapaciteten: Ger: httpd Du måste ha stött på ett fel när du försökte installera: "är ett virtuellt paket". Detta är vad det är :) |
Ger: supersh |
| underhållare | Namn och e-postadress för paketunderhållaren: personen som "debianiserade" programmet. Formatet är godtyckligt, men namnet accepteras |
Underhållare: o_O Tync |
| arkitektur | Processorarkitekturen som paketet är avsett för. Giltiga värden: i386, amd64, alla, källa allt används för skript: de är bärbara, eller hur? :) source används för kompilerade källkodspaket |
Arkitektur: allt |
| Sektion | Anger uppgiften som applikationen vanligtvis används för (applikationsgrupp). Möjliga värden: admin, base, comm, contrib, devel, doc, editors, electronics, embedded, games, gnome, graphics, hamradio, interpreters, kde, libs, libdevel, mail, math, misc, net, news, non-free , oldlibs, otherosfs, perl, python, vetenskap, skal, ljud, tex, text, utils, webb, x11 |
Avsnitt: Övrigt |
| Beskrivning | Beskrivning av paketet. Beskrivningen består av två delar: en kort beskrivning (70 tecken) på samma rad och en lång beskrivning på efterföljande rader, börjar med ett mellanslag. I den utökade beskrivningen ignoreras alla nyrader. \n infogas med en enda prick. |
Beskrivning: kort. ␣Lång ␣går hit. ␣. ␣Ny linje. |
| - kopplingar och beroenden - | ||
| Beror på | En kommaseparerad lista över paket som krävs för att installera det här paketet. Efter paketnamnet kan du ange en versionsgräns inom parentes med hjälp av operatorerna:<<, =, >>, <=, >=. Om operatorn inte anges används >=. |
Beror på: dpkg, libz (>= 1.2.3), jpeg (= 6b), png (< 2.0) |
| Beror i förväg | Lista över paket som krävs under installationen av detta paket. Dessa beroenden kan krävas för paketinstallationsskript: till exempel kräver flash-installer-paketet wget Du kan använda versionsbegränsningar (se Beror). |
Pre-Depends: wget (>= 1.0) |
| Konflikter | Lista över paket som inte kan installeras samtidigt som detta. Installationen misslyckas om minst ett av de listade paketen redan är installerat. |
konflikter: crapscript |
| Ersätter | Lista över paket vars filer modifieras av detta paket. Krävs om du skapar ett "patchpaket" som ändrar något: annars kommer ett installationsfel att uppstå när du byter ut filerna i någon annans paket. Jag har till exempel ett sådant paket som patchar UT2004 och tar bort ljudet från en målsökande raketgevär :) |
Ersätter: ut2004 |
| Rekommendationer | Lista över paket som rekommenderas för installation Dessa paket är valfria, men används vanligtvis tillsammans med strömmen |
Rekommenderas: superplattform |
| Förslag | Lista över paket som erbjuds för installation. Dessa paket är valfria, men programmet fungerar ännu bättre med dem :) I teorin borde pakethanteraren erbjuda att installera dem. |
Föreslår: supersh-moduler |
| Bygg-beror | (Endast för arkitektur: källa) Lista över paket som krävs för att kompilera källor. Samma som Depends, men logiskt åtskilda. |
Bygg-beror: cmake |
| - extra - | ||
| Installerad-storlek | Paketfilernas storlek i kilobyte. Bara ett tal avrundat till närmaste heltal. Används av pakethanteraren för att bestämma det totala diskutrymmet som krävs. |
Installerad storlek: 3 |
| prioritet | Paketprioritet: hur viktigt det är i systemet Möjliga värden: extra, valfritt, standard, viktigt, obligatoriskt (sådana paket tas inte bort alls!). |
Prioritet: valfritt |
| Grundläggande | Om du ställer in detta attribut till "ja" kan paketet inte tas bort. | Viktigt: ja |
| Ursprung | String: varifrån kommer programmen i paketet. Vanligtvis används webbadressen till författarens webbplats, e-post eller namn. | Ursprung: hjärna |
| X källa | Fullständig länk till *.tar.gz källarkiv | X-källa: ...*.tgz |
O_O Tync
Att arbeta med paketinstallationsskript kommer att diskuteras senare.
Tack Condorious för tipset :)
# ======[ Trap Errors ]======#
set -E # låt skalfunktioner ärva ERR-fällan
# Fånga icke-normala utgångssignaler:
# 1/HUP, 2/INT, 3/AVSLUTA, 15/TERM, ERR
trap err_handler 1 2 3 15 ERR
function err_handler(
local exit_status=$(1:-$?)
logger -s -p "syslog.err" -t "ootync.deb" "supersh.deb script "$0" felkod $exit_status (rad $BASH_LINENO: "$BASH_COMMAND")"
avsluta $exit_status
}
Din inställningsskriptkod...
VARNING: skivan har ännu inte testats allmänt, kolla igen! Jag stötte på omöjligheten att felsöka ganska nyligen :)
Mall - unik (inom samma paket) mallidentifierare. Om ett skript behöver anropa en specifik dialogruta används detta namn.
Typ - malltyp. Följande typer är definierade: sträng, lösenord, boolean, välj, multiselect, text, not, error.
Default-value - standardvärdet: användaren kan helt enkelt acceptera det.
Beskrivning - som i kontrollfilen består den av två fält: en kort beskrivning och lång text. Den första är titeln på "fönstret", den andra är en mer detaljerad beskrivning av vad som krävs av användaren. Det rekommenderas att inte använda ord som "enter", utan omedelbart essensen: "Script-hälsning", "Mount point", ...
| Typ | Mallbeskrivning |
|---|---|
| sträng | Textsträngprompt |
| Lösenord | Lösenordsprompt. Det finns inget standardvärde för denna malltyp av uppenbara skäl :) |
| booleskt | Bockmarkering :) Har strängvärdet "true" eller "false" |
| Välj | Möjlighet att välja ett av flera alternativ. Val: ja, nej, kanske |
| flera val | Möjlighet att välja flera alternativ med kryssrutor. Alternativ erbjuds i ytterligare ett mallattribut: Val: sex, droger, rock-n-roll |
| text | Visar text: vissa inte särskilt viktig information |
| notera | Visar text: viktig information |
| fel | Visar text på skärmen: mycket viktig information, kritisk. |
# Ansluta debconf-kommandon
Fodral "$1" in
konfigurera|omkonfigurera)
# Begäran
# Hantera svaret
hälsning="$RET"
echo "$greeting" > /etc/supersh/greeting.txt
;;
*)
echo "config anropad med okänt argument \`$1"" >&2
utgång 1
;;
esac
# Begäran
db_input medium "supersh/hälsning" || sann # initiering
db_go || sant # visa begäran på skärmen
# Hantera svaret
db_get "supersh/greeting" # Hämta värde i $RET-variabeln
hälsning="$RET"
echo "$greeting" > /etc/supersh/greeting.txt
Här ligger redan ett obehagligt bakhåll: observera att prioritet för mediumdialogen överförs till db_input-funktionen. För debconf kan du ställa in en lägsta prioritet: dialoger med en prioritet under vilka inte visas, men standardvärdet (Standard för mallen) tas! För att förhindra EXAKT detta från att hända använder vi den kritiska prioriteten :) Dessutom, vid installation från GUI, är tröskeln för att visa frågor högre, och många av dem visas inte alls.
Möjliga prioriteringar är: låg - standard används alltid, medium - standard är vanligtvis ganska lämplig, hög - standard är oönskat, kritisk - användarens uppmärksamhet är avgörande.
|| true används för att förhindra att skriptet dör på grund av alternativet "-e" som skickats till bash.
I det här skriptet rekommenderas det också att använda den grisen för att fånga fel, annars kan det omdistribuerbara paketet få problem vid felsökning :)
Alla finesser med att använda debconf (funktioner, metoder, alternativ, felkoder) beskrivs i en ganska utförlig mana: man debconf-devel .
En sista sak: när ett paket tas bort med kommandot purge måste debconf också rensa paketinformationen från sin databas. Till exempel sparar den användarens val på db_input-frågor.
För att rensa upp denna data måste du lägga till följande i postinst-skriptet:
if [ "$1" == "rensning" ] && [ -e /usr/share/debconf/confmodule ] ; sedan
. /usr/share/debconf/confmodule
db_purge
fi
I vår verksamhet med att skapa ett enkelt arkiv spelar inte alla fält en grundläggande roll, utan används endast för att visuellt bestämma "vad är vad" :)
Jag kommer att försöka förklara processen att skapa deb-paket så tydligt som möjligt med hjälp av ruby-zookeper som exempel. Jag varnar dig direkt att förpackningsmetoden för ruby gems som jag beskrev är fel, det är bättre att använda gem2deb för detta, men eftersom bygg ruby-zookeper från källan med hjälp av gem2deb senaste versionen Jag lyckades inte, då är här den enklaste monteringsmetoden.
Om du ska bygga rubinpaket via gem2deb som rekommenderat är det bättre att lägga till raden
Exportera DH_RUBY_IGNORE_TESTS=alla/exportera DH_RUBY_IGNORE_TESTS=alla
i debian/regler.
Därför att Eftersom vi kommer att bygga ruby-kod kommer vi att behöva ruby och en uppsättning verktyg för att bygga deb-paket.
sudo apt-get installera ruby dpkg-dev
Om du har en gammal version av ruby så har den inget gem-kommando, du måste också installera rubygems-paketet eller uppdatera ruby.
Låt oss nu installera pärlan fpm, som hämtar deb-paketet åt oss.
sudo gem installera fpm fpm -s gem -t deb zookeeper
I den nuvarande katalogen har vi paketet rubygem-zookeeper_1.4.11_amd64.deb, det verkar som att ärendet redan är i bagaget, men eftersom vi behöver ett källpaket så att vi kan bygga en deb av det, till exempel i OBS, sedan fortsätter vi.
Skapa en byggkatalog
cp rubygem-zookeeper_1.4.11_amd64.deb ~/ cd mkdir -p ruby-zookeeper/fakeroot cd ruby-zookeeper/fakeroot
Låt oss extrahera innehållet i det nybyggda paketet i det.
dpkg-deb -R ~/rubygem-zookeeper_1.4.11_amd64.deb ruby-zookeeper_1.4.11-1
Nu kommer vi att skapa de filer som behövs för att bygga paketet. De måste finnas i debiankatalogen. Vi kan kopiera några av filerna från det uppackade paketet.
mkdir debian cp rubygem-zookeeper_1.4.11-1/DEBIAN/control debian/control
Låt oss redigera det till nästa tillstånd. Glöm inte att byta underhållare
Källa: ruby-zookeeper Maintainer:
Vi behöver fortfarande debian/regler. Låt oss skapa det. override_dh_shlibdeps behövs för att inte kontrollera länkningen av djurskötares bibliotek, eftersom hon kommer inte igenom.
#!/usr/bin/make -f # -*- makefile -*- %: dh $@ override_dh_shlibdeps: true
Flikar i debian/regler krävs, du kan inte ersätta dem med mellanslag. Låt oss göra det körbart.
Chmod +x debian/regler
Usr/* var/*
Låt oss nu skapa debian/changelog och skriva där:
Ruby-zookeeper (1.4.11-1) OSLÄPPAD; urgent=medium * Initial release -- root
Vi behöver också debian/compat
Echo 7 > debian/compat
Låt oss kopiera filerna som kommer att installeras till en lokal katalog och radera mappen med det uppackade paketet, vi behöver det inte längre.
Mv ruby-zookeeper_1.4.11-1/(usr,var) . rm -r ruby-zookeeper_1.4.11-1
Låt oss bygga ett nytt paket, såväl som ett källpaket.
dpkg-buildpackage -rfakeroot -uc -F
I katalogen ovan kommer vi att ha alla nödvändiga filer.
Ll .. totalt 5528 drwxr-xr-x 3 rotrot 4096 dec 20 13:32 ./ drwx------ 12 rot rot 4096 dec 20 13:31 ../ drwxr-xr-x 5 rot rot 4096 dec 20 13:28 fakeroot/ -rw-r--r-- 1 rotrot 1261 20 dec 13:32 ruby-zookeeper_1.4.11-1_amd64.changes -rw-r--r-- 1 rotrot 2375044 20 dec 13: 32 ruby-zookeeper_1.4.11-1_amd64.deb -rw-r--r-- 1 rotrot 565 20 dec 13:32 ruby-zookeeper_1.4.11-1.dsc -rw-r--r-- 1 rotrot 3263381 20 dec 13:32 ruby-zookeeper_1.4.11-1.tar.gz
Du kan kontrollera innehållet i det resulterande deb-paketet
Skapa en lista med paket:
$ dpkg-scanpackages . /dev/null | gzip -9c > ./Packages.gzKanske får vi ett meddelande som:
dpkg-scanpackages: warning: Paket i arkivet men saknas från åsidosättningsfilen: dpkg-scanpackages: warning: fossil linux-headers-3.8.0-avl9-pae linux-image-3.8.0-avl9-pae pdfsam sublimetext virtualbox-4.2 xserver -xorg-input-wacom zotero dpkg-scanpackages: info: Skrev 8 poster till utdatapaketfilen.
Vi har nu 8 paket i vårt förråd. Ok, låt oss lägga till vårt arkiv till filen:
Deb file:///home/username/zips/virensdebianrepository ./
Nu måste du uppdatera listan över paket så att de blir tillgängliga för installation:
# apt-get install sublimetext
Särskilt tack till Com. hjärnström, som påpekade en bugg i ett inlägg med rendering av PRE-miljön. Detta händer när du litar på Haskell hantverk som Pandoc :-)
Ja, om du har något att tillägga - skriv i kommentarerna, men tänk på att inlägget är i hast, utan att behöva läsa om Debian Packaging Guidelines tomes och annan kvantfysik.
Anonyma kommentarer...
Det finns ett fel i din text:
"Nu, för att installera Skype, gör bara:
# apt-get install sublimetext"
Anonyma kommentarer...
Du kan packa upp paket med dpkg-deb:
$ dpkg-deb -x what.deb var/
Anonyma kommentarer...
Jag har alltid använt dpkg -e och dpkg -x för att helt packa upp ett paket och snabbt redigera filer eller beroenden i kontrollfiler. Jag använde också checkinstall istället för make install för att skapa ett paket när jag kompilerade något. Jag tycker att dessa verktyg är värda att nämna.
virens kommentarer...Att bygga paket från källkod i Debian är ont! Jag minns nu min erfarenhet:
1. Deb-paketet måste innehålla en underhållare och annat nonsens, utan vilket (surprise-surprise!) paketet inte kommer att byggas.
2. Har du monterat, installerat och tror att det är det? Ingen lycka, bra begåvning kan blåsa ett paket åt helvete när du installerar något annat. Du känner igen den där känslan: hur? Var? Vad? Jag har redan installerat det här paketet! Tja, detta är hans begåvning - han själv är ortodox, vilket betyder att han är patriarkal och inte tillåter fritt tänkande.
3. Därför behövs en manöver akut: aptitude hold package. "Vadå, håller den bra? Och var nu snäll - ta bort den!" (c) För från och med nu kommer aptitude att klaga på att den inte kan lösa beroenden utan att riva ner ditt paket.
4. Vid det här laget släppte mina nerver... Och jag upptäckte Gentoo, och mitt hår blev mjukt och silkeslent igen!
virens kommentarer...@iv_vl kommentarer...
Och jag upptäckte Gentoo och mitt hår...
Fräck PR Genta?! I min bloggare??? Det finns inget sätt! ;-)
1. Deb-paketet måste ha en underhållare och annat nonsens
Standardpolicy - du måste veta vem du ska slå i ansiktet för ett trasigt paket :-) Och sedan är det annorlunda bättre än så bedlam som pågår i RPM fedoras och zyuzes.
2. Har du monterat, installerat och tror att det är det? Ingen lycka, bra begåvning kan blåsa ett paket åt helvete när du installerar något annat.
Bara om du lägger ett paket gammal version- Jag har till exempel ett tag på IceWM, som jag installerade från Lenny (idiotunderhållaren stoppade is med en trasig bricka i Squeeze). Aptitude kommer att varna dig före sådana manövrar, om något.
3. Därför behövs en manöver brådskande: aptitude hold-paket... aptitude kommer att svära på att det inte kan lösa beroenden
Det här är en lögn och en provokation: om du inte tar tag i något som gcc eller glibc, kommer det normalt att lösa beroenden. Till skillnad från RPMs, som gillar att ge upp omedelbart i stil med "Nja, jag kunde inte, jag kunde inte" :-)
Det kan finnas problem med felsökning, det är ett faktum, men det är bättre än att steka bacon och ägg på CPU:n medan man väntar på att färsk KDE-gentoy ska bli klar...
4. På detta gick mina nerver över ...
På något sätt sprängdes du snabbt. Hur är det förresten med beroenden i Gent? Hur lever du där med svordomar vid varje nysning?
Jag ... inte trollar för ... folk är intresserade.
