Jaka jest różnica między budowaniem ze źródła a używaniem pakietu instalacyjnego?

Zastanawiałem się: podczas instalowania czegoś istnieje prosty sposób podwójnego kliknięcia pliku wykonywalnego instalacji, a z drugiej strony istnieje sposób na zbudowanie go ze źródła.

Ten ostatni, pobieranie pakietu źródłowego, jest naprawdę kłopotliwy.

Ale jaka jest fundamentalna różnica między tymi dwiema metodami?

Całe oprogramowanie to programy , które są również nazywane pakietami źródłowymi . Wszystkie pakiety źródłowe muszą być najpierw zbudowane , aby działały w twoim systemie.

Te pakiety binarne są jednym, które są już budować od źródła przez kogoś z ogólnych cech i parametrów przewidzianych w programie tak, że duża liczba użytkowników może zainstalować i używać.

Pakiety binarne są łatwe do zainstalowania .
Ale może nie mieć wszystkich opcji z pakietu nadrzędnego.

Aby więc zainstalować ze źródła, musisz sam zbudować kod źródłowy. Oznacza to, że musisz sam zająć się zależnościami. Musisz także pamiętać o wszystkich funkcjach pakietu, aby odpowiednio go zbudować.

Zalety instalacji ze źródła:

• Możesz zainstalować najnowszą wersję i zawsze być na bieżąco, niezależnie od tego, czy jest to poprawka bezpieczeństwa, czy nowa funkcja.
• Umożliwia ograniczenie funkcji podczas instalacji, tak aby odpowiadały Twoim potrzebom.
• Podobnie możesz dodać niektóre funkcje, które mogą nie być zawarte w pliku binarnym.
• Zainstaluj go w wybranym miejscu.
• W przypadku niektórych programów możesz podać informacje o swoim sprzęcie dla właściwej instalacji.

Krótko mówiąc, instalacja ze źródła daje dużą opcję dostosowywania , a jednocześnie wymaga dużo wysiłku, podczas gdy instalacja z pliku binarnego jest łatwiejsza, ale dostosowanie może być niemożliwe .

Aktualizacja : dodanie argumentu dotyczącego bezpieczeństwa w komentarzach poniżej. Tak, to prawda, że ​​podczas instalacji z pliku binarnego nie masz integralności kodu źródłowego. Ale to zależy od tego, skąd masz plik binarny. Istnieje wiele zaufanych źródeł, z których można uzyskać plik binarny każdego nowego projektu, jedynym minusem jest czas . Pliki binarne aktualizacji lub nawet nowy projekt mogą pojawić się w naszych zaufanych repozytoriach.

A przede wszystkim, jeśli chodzi o bezpieczeństwo oprogramowania, chciałbym podkreślić tę zabawną stronę w dzwonnicach dostarczonych przez Joe w poniższych komentarzach.

Plik źródłowy zawiera oryginalny kod napisany przez programistę w dowolnym wybranym przez niego języku (C, C ++, Python itp.) I jest ogólny. Nie jest specyficzny dla żadnej dystrybucji, aw wielu przypadkach dla żadnego systemu operacyjnego.

Pakiet (na przykład RPM lub DEB) to binarny plik wykonywalny (lub zinterpretowany skrypt itp.) Wstępnie przygotowany dla konkretnej dystrybucji. Zadanie przygotowania źródła do kompilacji (dodanie niezbędnych poprawek itp.), Faktyczna kompilacja, tworzenie plików konfiguracyjnych specyficznych dla dystrybucji, tworzenie skryptów przedinstalacyjnych i poinstalacyjnych itp. Są wykonywane przez opiekuna pakietu.

Innymi słowy, cała praca z osłem została wykonana dla ciebie w pakiecie, ale będziesz musiał zrobić to sam, jeśli zdecydujesz się zainstalować ze źródła.

O wiele łatwiej jest użyć pakietu w prawie wszystkich przypadkach, ponieważ:

• Są znacznie łatwiejsze do zainstalowania
• Są one specjalnie zaprojektowane do pracy z Twoją dystrybucją
• Czasami są one załatane przez opiekuna pakietu, aby naprawić błędy specyficzne dla dystrybucji
• Menedżer pakietów je odinstaluje
• Menedżer pakietów zarządza za Ciebie wszystkimi zależnościami
• Menedżer pakietów zajmie się aktualizacjami
• Nie musisz instalować narzędzi programistycznych w swoim systemie (kompilatory, make itp.)

Czasami jednak wersja spakowana jest wersją starą lub, co gorsza, nie ma wersji spakowanej; w takim przypadku jedyną opcją jest samodzielne skompilowanie. Jeśli to zrobisz, musisz wziąć pod uwagę następujące kwestie:

• Musisz zainstalować wszystkie narzędzia programistyczne w swoim systemie
• Będziesz odpowiedzialny za sprawdzenie aktualizacji i ponowną kompilację
• Musisz upewnić się, że wszystkie zależności są zainstalowane, w tym devpakiety - może być ich wiele.
• Może być konieczne debugowanie problemów, jeśli nie działa zgodnie z oczekiwaniami w dystrybucji

Jeśli chcesz włożyć dodatkowy wysiłek, wówczas kompilacja ze źródła może zapewnić następujące korzyści:

• Dostęp do najnowszej dostępnej wersji
• Opcja optymalizacji procesu kompilacji pod kątem wydajności / stabilności
• Przyjemność!

Zauważ, że chociaż niektóre wstępnie przygotowane pakiety niektórych dystrybucji zawierają binarne pliki wykonywalne, które są gotowe do zainstalowania i uruchomienia (przykłady to RPM i DEB), inne dystrybucje zapewniają pakiety, które po prostu automatyzują proces kompilacji.

Gentoo ebuildsjest tego przykładem - pakiet jest w zasadzie instrukcjami dla menedżera pakietów opisującymi, jak skompilować i zainstalować plik wykonywalny. Ma to wiele zalet tradycyjnych menedżerów pakietów (automatyczne aktualizacje, odinstalowywanie itp.), A jednocześnie pozwala użytkownikowi zoptymalizować proces kompilacji według własnego gustu.

Arch Linux ma system pakowania, w którym pakiety głównego nurtu są binarne, podczas gdy wiele dodatkowych pakietów jest kompilowanych w systemie za pomocą PKGBUILDplików.

Oprócz innych odpowiedzi chciałbym coś dodać:

Jeśli zdecydujesz się skompilować program sam, musisz pomyśleć, że kompilacja nie jest czymś, co robisz tylko raz. Prawdopodobnie będziesz musiał zasubskrybować listę programistyczną aplikacji, które zdecydowałeś się skompilować i być na bieżąco z nowymi wersjami, a zwłaszcza aktualizacjami zabezpieczeń.

Za każdym razem, gdy aplikacja jest aktualizowana, będziesz musiał ponownie skompilować nową wersję, więc pamiętaj, że będziesz musiał poświęcić trochę czasu co tydzień.

Jeśli nie możesz sobie na to pozwolić, lepiej pozwolić opiekunowi pakietu wykonać to zadanie za ciebie.

Budowanie ze źródła pozwala określić architekturę dokładnie twojej maszyny. Nowe procesory mają dodatkowe instrukcje, które kompilatory rozumieją, zmniejszając nieco wydajność. Pakiety przed kompilacją zwykle polegają na najbardziej archaicznym procesorze, który jest nadal w powszechnym użyciu.

Jest to szczególnie ważne w przypadku aplikacji krytycznych dla projektu, które bardzo intensywnie wykorzystują procesor, takich jak na przykład narzędzia rurociągu bioinformatycznego lub narzędzia do modelowania geofizycznego. Takie oprogramowanie działa w ściśle kontrolowanym środowisku, nie ma kontroli dostępu, więc rzadko występują błędy bezpieczeństwa tak pilne, że należy je załatać w ciągu kilku dni lub godzin. Prawie nigdy nie musi działać na innym komputerze z początkowo nieznaną architekturą.

Tak, wiem, komputery są teraz bardzo, bardzo, bardzo szybkie, a wszelkie podejmowane wysiłki lub działania są bardzo, bardzo drogie, ale trzeciego dnia siedzenia i oczekiwania na zakończenie programu (taka jest sytuacja, o której mówię) takich prawd zacznij wyglądać na wątpliwe.

Innymi słowy, aplikacje takie jak przeglądarki i tym podobne powinny być lepiej wykorzystywane z repozytorium opiekuna (a nie z niektórych pobranych gotowych pakietów), ponieważ bardzo ważne jest, aby je aktualizować.

Jednym ze sposobów na uzyskanie najlepszego z obu światów (aktualne oprogramowanie, prosta instalacja / deinstalacja, włączenie większości poprawek i adaptacji dystrybucji, można zoptymalizować pod kątem lokalnych wymagań), podczas gdy koszty (trzeba być na bieżąco, uważać na błędy) i łatki w ostatniej chwili, śledź rozwój, jesteś sam w odniesieniu do poprawek błędów i niezgodności między wersjami) nie można złagodzić (dużo), jest budowanie własnych pakietów, zaczynając od pakietów źródłowych z twojej dystrybucji. Tak, to więcej pracy niż budowanie i instalacja.