Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
Pełny tytuł: Wszystko jest kodem programu? Rozważania o menedżerze oprogramowania w Linux
Tło
Zastanawiam się nad działaniem menedżera oprogramowania (“portage”) w Gentoo Linux (który mam zainstalowany). Wiadomo, że oprogramowanie w tym systemie przeważnie jest budowane ze źródeł, a pliki “*.ebuild” zawierają informacje o poszczególnym oprogramowaniu w postaci rozszerzonego skryptu powłoki.
Problem
Podczas aktualizacji systemu występują notorycznie problemy z zależnościami, które blokują tę aktualizację z powodu niemożności jednoczesnej instalacji oprogramowania w różnych wersjach. Menedżer oprogramowania nie jest w stanie sobie poradzić. Do niektórych grup oprogramowania (np. modułów Perla) zostały utworzone osobne programy rozwiązujące te zależności, ale do innych nie.
Zastanawiam się nad tym, jak utworzyć lepszy menedżer oprogramowania.
Abstrakt
Opis pojedynczej paczki oprogramowania jest tworzony przez skrypt, który przekazuje wynikowe zmienne otoczenia oraz zawiera procedury uzupełniające/zastępujące poszczególne kroki budowania tego oprogramowania. Czyli jeśli nie wykonuje się budowania tego oprogramowania, to nie wiadomo, co należy zrobić w systemie, by je zainstalować. (Dodam tylko, że w celu ograniczenia pełnych możliwości robienia wszystkiego w systemie skrypt jest wykonywany jako użytkownik “portage”.)
Czy nie można by zrobić jakiegoś rodzaju bazy danych definicji:
1. co ma być zainstalowane w systemie dla pojedynczej paczki oprogramowania
2. jakie są zależności takiej pojedynczej paczki oprogramowania
Czyli miało by to formę danych opisu, a nie kodu programu, który może zrobić wszystko i wymaga sprawdzenia, czy nie robi czegoś nie chcianego przez użytkownika. Instalowane pliki byłyby tylko w obszarze przynależnym do pojedynczego oprogramowania.
No i nie byłoby wymagane uzgadnianie integralności pełnej bazy danych paczek dostępnych w systemie przez osoby zarządzające dystrybucją systemu, ponieważ jeśli jakiś program nie byłby zgodny z nową wersją zależnego oprogramowania, to w systemie pozostawałaby stara wersja do czasu aktualizacji przez autorów oprogramowania.
Wymagana byłaby tylko opieka nad poszczególnym oprogramowaniem niezależnie od jego wersji: oznaczanie w nim wersji, które dokonują jakichś zmian interfejsu zewnętrznego. A to mogliby robić nawet autorzy oprogramowania, gdy dokonywaliby oznaczania kolejnej wersji.
Kwestie końcowe
Jak to jest rozwiązane w innych dystrybucjach systemu Linux, w innych menedżerach pakietów? Występują te same problemy konieczności pełnej integralności wersji dostępnego do instalacji oprogramowania w systemie? A może ktoś coś napisze o menedżerach oprogramowania z innych systemów operacyjnych (uniksopodobnych), które rozwiązują ten problem?
Ostatnio edytowany przez overcq (2024-11-17 07:22:23)
Offline
Pytanie. Po co kompilować sobie zycie?
Wybierz distro oparte na paczkach.
Offline
Po pewnym czasie doświadczeń z Gentoo też wybrałbym taką dystrybucję, ale… okazało się, że:
‣ ‟wpa_supplicant” na mojej karcie nie działa bez zastosowania ‘patcha’ wyłączającego “scs” i “mscs”
‣ ‟nvidia-drivers” w wersji zachowanej wcześniej nie działa z nowym kernelem i potrzebuje ‘patchy’ (tak samo jak kernel)
Mam laptopa z 2013 roku i dzięki temu on jeszcze funkcjonuje, nawet akceleracja 3d.
⁂
A wracając do tematu. Czy w systemie paczek jest możliwość instalacji/zatrzymania starych wersji oprogramowania, podczas gdy większość jest aktualizowana?
Offline
w systemach z " paczkami" jest możliwość zatrzymania starych wesji paczki. Ale Najlepiej jest zbudować/skompilować (przynajmniej spróbować) stara wersje oprogramowania na nowych zależnościach zastanych aktualnie na systemie.
Offline
W debianie to co jest w repo w postaci paczki, masz skonfigurowane to w taki sposób by to działało na największej liczbie stacji roboczych i spełniało wymagania jak największej liczby użytkowników. Jeśli z jakichś powodów taka paczka nie spełnia twoich wymagań, to zawsze możesz ja sobie sam zbudować w oparciu o przygotowane źródła (tj. o to z czego powstał pakiet dystrybucyjny). Na te źródła możesz sobie nakładać patch'e i co jakiś czas przebudowywać je by aktualizować wersje zależności. Możesz sobie zatrzymać dowolny pakiet w systemie, by nie był aktualizowany albo określić mu apt pinning i np. zrobić sobie lokalne repozytorium, do którego tak lokalnie budowane/zmienione pakiety będą trafiać. Rozwiązań jest sporo. Niemniej zależności to zależności, im dłużej pakiet będzie w systemie zatrzymany, tym więcej tych zależności może zostać zatrzymana w procesie aktualizacji i w skrajnych przypadkach (jeśli są to podstawowe komponenty systemu) to nie dasz rady nic zaktualizować. xD
Np. ja od jakiegoś czasu mam zablokowane:
# apt-mark showhold gsmartcontrol # apt-cache policy gsmartcontrol gsmartcontrol: Installed: 1.1.4-1 Candidate: 2.0.0-1 Version table: 2.0.0-1 990 990 https://deb.debian.org/debian sid/main amd64 Packages 500 https://incoming.debian.org/debian-buildd buildd-unstable/main amd64 Packages 1.1.4+git20240531.25f1c62-2 500 500 https://deb.debian.org/debian testing/main amd64 Packages *** 1.1.4-1 100 100 /var/lib/dpkg/status
Bo na tym nowszym smart nie da rady przeskanować dysku z jakiegoś powodu. Więc jak appka nie działa jak trza, to wersję pakietu sobie można w dowolnej chwili cofnąć i wszystko wraca do normy. Zwykle problemy są tymczasowe i nie ma potrzeby zatrzymywania pakietu, bo z następną aktualizacją zwykle już stosowne poprawki naniosą ale jak potrzeba zatrzymać to bez problemu można. xD
A aktualizacja systemu wygląda później tak:
# aptitude full-upgrade The following packages will be upgraded: dns-root-data libaom3 libmbedcrypto16 libmbedtls21 libmbedx509-7 memtest86+ python3-precis-i18n strace The following packages will NOT be UPGRADED: gsmartcontrol 8 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded. Need to get 4,188 kB of archives. After unpacking 141 kB will be used. Do you want to continue? [Y/n/?]
Offline
Strony: 1