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!

Ogłoszenie

Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.

#1  2024-11-17 07:10:36

  overcq - Nowy użytkownik

overcq
Nowy użytkownik
Zarejestrowany: 2024-11-17
Spam…

Ro­zważa­nia o me­ne­dże­rze oprogra­mo­wa­nia w Linux

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)


Nie znam się, ale się wypowiem.

Offline

 

#2  2024-11-17 20:26:44

  Yampress - Imperator

Yampress
Imperator
Zarejestrowany: 2007-10-18

Re: Ro­zważa­nia o me­ne­dże­rze oprogra­mo­wa­nia w Linux

Pytanie. Po co kompilować sobie zycie?
Wybierz distro oparte na paczkach.

Offline

 

#3  2024-11-18 06:01:38

  overcq - Nowy użytkownik

overcq
Nowy użytkownik
Zarejestrowany: 2024-11-17
Spam…

Re: Ro­zważa­nia o me­ne­dże­rze oprogra­mo­wa­nia w Linux

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?


Nie znam się, ale się wypowiem.

Offline

 

#4  2024-11-18 09:24:26

  Yampress - Imperator

Yampress
Imperator
Zarejestrowany: 2007-10-18

Re: Ro­zważa­nia o me­ne­dże­rze oprogra­mo­wa­nia w Linux

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

 

#5  2024-11-18 10:15:52

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Ro­zważa­nia o me­ne­dże­rze oprogra­mo­wa­nia w Linux

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:

Kod:

# 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:

Kod:

# 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

 

Stopka forum

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
Możesz wyłączyć AdBlock — tu nie ma reklam ;-)