Ostatnio dowiedziałem się jak łatwo jest uzyskać kod źródłowy dla dowolnego pakietu używając apt-get source
, dzięki czemu mogę uzyskać kod źródłowy, wprowadzić zmiany i zainstalować własną zmodyfikowaną wersję dowolnego pakietu. To jest świetne!
Do dzisiaj zakładałem, że każdy pakiet będzie miał swój własny kod źródłowy, i że różne pakiety będą miały różne kody źródłowe.
Jednak teraz właśnie odkryłem, że różne pakiety mogą mieć identyczny kod źródłowy. Oto przykład takiego działania:
Następujące 4 pakiety wydają się mieć identyczny kod źródłowy:
gir1.2-mutter-4
libmutter-4-0
mutter
mutter-common
Wszystkie cztery z nich są zainstalowane na moim komputerze Ubuntu 19.04. Wykonanie apt-get source gir1.2-mutter-4
daje dokładnie taki sam wynik jak apt-get source libmutter-4-0
, a także dla pakietów mutter
i mutter-common
.
Oto jak to sprawdziłem:
mkdir a
cd a
apt-get source gir1.2-mutter-4
cd ..
mkdir b
cd b
apt-get source libmutter-4-0
cd ..
diff -r a b
Rekursywny diff w ostatniej linii powyżej nie daje żadnych danych wyjściowych, pokazując, że katalogi mają identyczną zawartość.
Przejdźmy teraz do mojego pytania: **Jak to możliwe, że różne pakiety mają identyczny kod źródłowy?
Zakładając, że jest to zamierzone i nie jest to jakiś błąd, jaka jest różnica między pakietami i jak mogę ją zobaczyć?
Czy może być tak, że pakiety różnią się sposobem w jaki kod źródłowy jest konfigurowany i kompilowany, np. różne części kodu są zawarte w różnych pakietach? Jeśli tak, to gdzie mogę znaleźć informacje o tym, jak skonfigurować każdy z pakietów?
Edit: zapomniałem dodać, że jeśli chcesz to przetestować, aby apt-get source
działał poprawnie, możesz potrzebować najpierw włączyć go używając software-properties-gtk
jak opisano tutaj: https://askubuntu.com/a/857433/874649
Edytuj 2: dzięki za doskonałe odpowiedzi! Znalazłem również to pomocne https://askubuntu.com/a/246721/874649 -- o komendach apt-get build-dep
i dpkg-buildpackage
, które są bardzo przydatne. Po zmodyfikowaniu kodu źródłowego pakietu źródłowego, dpkg-buildpackage -us -uc
może być użyty do zbudowania nowych plików .deb, które mogą być użyte do zainstalowania zmodyfikowanego programu(ów).
Mylisz zbudowane pakiety binarne z bazowym kodem źródłowym/pakietem, z którego te pakiety zostały zbudowane.
Pakiety, do których się odnosisz są zbudowane z tego samego kodu/pakietu źródłowego, mutter
. Możesz to łatwo znaleźć wchodząc na stronę packages.ubuntu.com
, wyszukując pakiet, którego szukasz, a następnie odnieść się do "Pakietu źródłowego", do którego się odnosi. Który w tym przypadku jest mutter
:
Stamtąd, jednakże, możemy sprawdzić stronę Launchpada dla pakietu źródłowego Mutter's i zobaczyć, że buduje on wiele pakietów binarnych (zbudowany skompilowany kod źródłowy, itp. do instalacji):
Te opisy opisują co każdy pakiet zawiera/instaluje. Skupiając się na 4 pakietach, które wskazałeś, i używając tych opisów:
gir1.2-mutter-4
- dane introspekcji GObject dla Mutter (używane przez gir
i GObject jako biblioteki/dane do interakcji Mutter i GObject)libmutter-4-0
- Biblioteka bazowa dla menadżera okien Mutter. (Używana do rozwoju wtyczek, rozwoju i kompilacji integracji Mutter, itp. zazwyczaj)mutter
- rzeczywisty menedżer okien Mutter, który używa biblioteki menedżera okien GNOME'a (dlatego potrzebny jest GObject)mutter-common
- współdzielone pliki dla Mutter - zwykle domyślne opcje konfiguracyjne lub elementy, które są wspólne dla wszystkich pakietów zbudowanych z pakietu źródłowego.To co'widzisz na liście pakietów to zbudowane pakiety, które pochodzą z tego samego kodu źródłowego - każdy pakiet to różne elementy instalowane po czasie kompilacji i używane do różnych rzeczy. Możesz zobaczyć, co'jest w samych pakietach poprzez pobranie poszczególnych pakietów, a następnie dostęp do nich za pomocą p7zip lub wbudowanego w Ubuntu Menedżera Archiwów i zobaczyć różnice w tym, co każdy pakiet zawiera w ten sposób. *Wszystkie one pochodzą z tego samego kodu źródłowego - po prostu zawierają różne elementy, które są instalowane* do systemu.
Pakiety źródłowe i pakiety binarne istnieją oddzielnie. Każdy pakiet źródłowy może mieć wiele powiązanych z nim pakietów binarnych. Oznacza to, że więcej niż jeden pakiet binarny może być zbudowany z tego samego pakietu źródłowego.
Jednym z najczęstszych sposobów, w jaki to się dzieje, jest posiadanie programu, biblioteki, której program używa do wykonania większości swoich zadań, oraz plików nagłówkowych używanych do skompilowania go i innych (być może przyszłych) programów, które używają tej biblioteki. Wszystkie one są rozwijane i utrzymywane w tym samym drzewie źródłowym, które jest używane, z łatkami Debiana lub Ubuntu lub bez nich, do wygenerowania pakietu źródłowego. Następnie ten pakiet źródłowy jest używany do budowania oddzielnych pakietów binarnych dla programu, biblioteki i nagłówków.
To właśnie masz tutaj (z kilkoma innymi pakietami binarnymi również). W poleceniu apt source
podałeś różne pakiety binarne, ale polecenie pobiera i rozpakowuje ten sam pakiet źródłowy.
Dzieje się tak, ponieważ kiedy podasz nazwę pakietu do apt source
, ale nie ma pakietu źródłowego o tej nazwie, traktuje to jako nazwę pakietu binarnego i zakłada, że chcesz ten pakiet binarny'odpowiadający pakietowi źródłowemu.
Na głównej stronie Ubuntu na Launchpad, można szukać pakietów. Launchpad wyświetla informacje o pakietach źródłowych (podczas gdy Ubuntu Packages Search wyświetla informacje o pakietach binarnych). Jeśli wyszukujesz mutter
, to jak powiedział Thomas Ward znajdziesz stronę Launchpada dla pakietu źródłowego mutter
w Ubuntu. Jest to jeden z dobrych sposobów, aby zobaczyć, które pakiety binarne odpowiadają pakietom źródłowym. W pobliżu góry tej strony, to mówi:
mutter package in Ubuntu
gir1.2-mutter-4: dane introspekcji GObject dla Mutter libmutter-4-0: biblioteka menedżera okien z menedżera okien Mutter libmutter-4-0-dbgsym: Brak dostępnego podsumowania dla libmutter-4-0-dbgsym w ubuntu eoan.
libmutter-4-dev: Pliki rozwojowe dla menedżera okien Mutter mutter: Przykładowy menedżer okien wykorzystujący bibliotekę menedżera okien GNOME'a mutter-common: pliki współdzielone dla menedżera okien Mutter mutter-dbgsym: symbole debugowania dla muttera
Nawet jeśli pakiet binarny nie ma takiej samej nazwy jak pakiet źródłowy, z którego został zbudowany, zazwyczaj można znaleźć pakiet źródłowy, wyszukując go w Launchpadzie.
Często można dowiedzieć się, jaki jest związek między pakietem binarnym a pakietem źródłowym użytym do jego zbudowania poprzez sprawdzenie nazwy pakietu binarnego:
Nazwy pakietów binarnych zaczynające się od lib
zazwyczaj zawierają biblioteki kodu, które mogą być używane przez wiele programów (w tym przyszłe programy).
Te, które kończą się na -dev
dostarczają pliki nagłówkowe, które ułatwiają kompilację kodu źródłowego, który używa bibliotek.
Te, które kończą się na -dbg
lub -dbgsym
dostarczają symboli debugowania (więc nawet jeśli libmutter-4-0-dbgsym
nie pokazuje obecnie podsumowania, wiemy, że jest to pakiet symboli debugowania).
Te, które kończą się na -common
mają tendencję do dostarczania plików, często plików danych, które rezydują w /usr/share
. Takie pliki są czasami efektywnie kodem, tylko w statycznej i deklaratywnej formie, ale mogą także dostarczać tłumaczenia interfejsu na naturalne (tj. ludzkie) języki. Nie ma zbyt wielu ograniczeń co do tego, co może znaleźć się w takim pakiecie.
Dla mutter
, pakiet binarny -common
(w ostatnich wersjach) zawiera schematy, wiązania kluczy i dokumentację. Jedną z zalet pakietów -common
jest to, że ponieważ zazwyczaj nie zawierają one żadnego natywnego kodu maszynowego, ten sam plik pakietu jest zazwyczaj stosowany do wszystkich architektur. (Ściśle mówiąc, jest to jedno kluczowe wymaganie dla plików umieszczonych w /usr/share
).
Weź następujące składniki:
Czy można z nich zrobić tylko jedno danie? Nie. To, co ostatecznie zjesz, zależy od przepisu.
Każde opakowanie zawiera przepis. Mówi on komputerowi, co zrobić ze składnikami, aby uzyskać żądane danie(a).
Jest to rozsądne i normalne, że niektóre pakiety dzielą się listą składników. Oczywiście, w tym kontekście, spodziewałbyś się, że tak będzie w praktyce tylko wtedy, gdy pakiety pochodzą z tego samego projektu.