Skocz do zawartości

graterlia-scripts 0.1.66


Gość Setu

Rekomendowane odpowiedzi

Witam!

Dziś rano wklepałem odruchowo opkg update i upgrade (robiłem to również przed wczoraj) w moje ADB5800

i wyskoczyło mi coś niepokojącego :

 

GraterliaOS:~# opkg upgrade

Upgrading graterlia-scripts from 0.1.62 to 0.1.66 on root.

Downloading http://graterlia.xunil.pl/repodata/release/sh4/graterlia-scripts_0.1.66_sh4.ipk.

Configuring graterlia-scripts.

Collected errors:

* resolve_conffiles: Existing conffile /etc/sysconfig/system.conf is different from the conffile in the new package. The new conffile will be placed at /etc/sysconfig/system.conf-opkg.

 

No i rzeczywiście znacząco się te pliki różnią.

Podmienić je ręcznie ? Czy coś jest nie tak ?

Odnośnik do komentarza
Udostępnij na innych stronach

To nowa funkcjonalność w opkg w GOS (pierwsze testy niecały miesiąc temu były).

 

W GOS, jak w każdym systemie masz pliki konfiguracyjne, które zmieniasz zależnie od własnych potrzeb. Z drugiej strony masz osoby, które systemem zarządzają i wprowadzają konieczne zmiany. Na ekranie dostałeś informacje, że pewne zmiany zostały wprowadzone i teraz powinieneś we własnym zakresie sprawdzić co zostało zmienione i skorygować wpisy w pliku konfiguracyjnym, który został zmieniony. Skorygować znaczy "sprawdzić co się zmieniło i pomyśleć, czy wprowadzić to u siebie". Jeżeli nigdy nie zmieniałeś fragmentu, który został zmieniony przez developerów (jak to będzie po polsku?), to możesz wprowdzić zmianę u siebie.

Odnośnik do komentarza
Udostępnij na innych stronach

@mickey → bardzo dobrze to opisałeś.

Ja dodam, że sukcesywnie poprawię paczki, w których są pliki konfiguracyjne. Dzięki temu np. OSCam będzie mógł mieć konfigurację w paczce czy też inne oprogramowanie. Nic się nie nadpisze.

Dodatkowo dzisiaj dam aktualizację, w której system sprawdzi czy w ogóle jest plik. Jak jest to załaduje ustawienia z niego, a jak go nie będzie to załaduje ustawienia predefiniowane:

#deklaracje zmiennych
MODDIR=/lib/modules #ścieżka do katalogu z modułami jądra
if [ -e /etc/sysconfig/system.conf ]; then #załadowanie zmiennych z pliku system.conf
        . /etc/sysconfig/system.conf
else
        fscheck=on
        tmptmp=off
        varrun=64k
        varlog=32k
        sshd=on
        dts=off
        sci=nbox
        led=off
        vfd=off
fi

 

Plik system.conf dużo się zmienił w sensie usunięcia wielu ustawień. Sukcesywnie przechodzą na model Systemu Operacyjnego dużo ustawień realizowanych jest inaczej a od strony użytkownika wystarczy instalacja paczki przez system opkg.

Odnośnik do komentarza
Udostępnij na innych stronach

A nie lepiej byłoby odwrotnie. Zwykły user nie rozumiejąc poszczególnych parametrów konfigu nie wie przy czym zostać ( stary|nowy) a patrząc w dal zrobi się bałagan bo jeśli zaistnieje problem będziemy drążyć wątek zgadując na której konfiguracji user "jedzie".  Jest gałąź test i dajmy jej się rozwijać. Jeśli konfiguracja okaże się istotna dla funkcjonalności systemu niech widnieje w release już bez wyboru (stary|nowy) a w repo test proponowałbym nadpisanie konfiguracji po wcześniejszym wykonaniu kopii pliku np. z opcją backup.

Odnośnik do komentarza
Udostępnij na innych stronach

Nie, nie lepiej odwrotnie, bo już np. po dwóch zmianach nie masz oryginalnego pliku ... a sam coś tam zmieniałeś, co ma istotne znaczenie dla Ciebie. Robiłeś to tak dawno, że zapomniałeś co, ale jak nagle jakaś funkcja przestanie działać, to sobie przypomnisz... [miałem tak ostatnio z cronem].

 

A tak masz plik z końcówką "-opkg" i świadomość, że taki się pojawił, bo był komunikat na ekranie. Porównasz sobie diff-em, jeżeli coś kiedyś zmieniałeś w oryginalnym pliki i uzupełnisz. Jak nie zmieniałeś, to pewnie jesteś tego świadomy i możesz podmienić na nowy "bezmyślnie" (nie polecam tej metody).

Odnośnik do komentarza
Udostępnij na innych stronach

No tak tylko że jeśli już zmienię któryś parametr w oryginalnym konfigu na ten z "-opkg"  to i tak "pies pogrzebany" bo żaden update nie pomoże mi doszukać się co zmieniłem w oryginale bo plik "*.conf-opkg"  będzie niósł z sobą kolejne zmiany w stosunku do tego w którym zmieniałem, czyli reasumując całość na jedno wyjdzie.

Odnośnik do komentarza
Udostępnij na innych stronach

Trochę mylisz się. Zasada jest taka - chyba od zawsze.

Instaluje się system i są jakieś pliki konfiguracyjne. Traktuje się je jako przykładowe ale z nimi system wystartuje. Potem dopieszczasz sobie system, zmieniasz parametry itd. My tego nie wiemy - co użytkownik może być inaczej. Dlatego jak stwierdzamy, że jakiś parametr jest konieczny do zmiany to modyfikujemy plik. Jeżeli jakiś parametr będzie KONIECZNY do dodania będzie stosowny komunikat podczas aktualizacji/instalacji.

Podobnie będzie z innymi paczkami np. OSCam, ntpd, vsftpd, openvp, inne. W każdej paczce określimy jakie pliki to pliki konfiguracyjne i w razie zmian będzie osobny plik.

 

Mamy też wyjście inne. Możemy wrócić do modelu IMAGE. Wtedy dylematu nie będzie. Co aktualizacja każdy chcący mieć najnowszy system wgra wszystko od nowa i skonfiguruje raz jeszcze. Jednak uważam, że na obecnym etapie przyzwyczajenia się użytkowników Graterlia do aktualizacji z opkg jest to wyjście nie do przyjęcia.

 

Odnośnik do komentarza
Udostępnij na innych stronach

...

Mamy też wyjście inne. Możemy wrócić do modelu IMAGE. Wtedy dylematu nie będzie. Co aktualizacja każdy chcący mieć najnowszy system wgra wszystko od nowa i skonfiguruje raz jeszcze. Jednak uważam, że na obecnym etapie przyzwyczajenia się użytkowników Graterlia do aktualizacji z opkg jest to wyjście nie do przyjęcia.

 

A może trzecia droga? Dla tych co lubią koncpecję OS tak jak jest, a dla tych cowolą gotowca, koncepcja IMAGE. A ta wcale nie oznacza konfigurowanie wszystkiego po ugrade. Od tego jest kopia ustawień. ;)

Odnośnik do komentarza
Udostępnij na innych stronach

(...) a dla tych co wolą gotowca, koncepcja IMAGE. (...)

 

Dla tych pewnie jest to, pojawiająca się co jakiś czas info info na stronie z historią aktualizacji:

 

aktualizacja obrazów Graterlia OS w dziale Pobierz do wersji release 2014-06-16;

 

oraz praca richtera: http://forum.xunil.pl/index.php/topic,1444.0.html :)

Odnośnik do komentarza
Udostępnij na innych stronach

Zastanawiałem się nad tym. Kiedyś zainstalowałem to co jest w OPKG ze skórek i pluginów. Zabrakło 128MB. Jak założę, że osoba A czy B potrzebuje tego czy tamtego to nagle wejdą osoby C i D...

Dlatego co do skórek i pluginów to te najczęściej używane są po prostu do instalacji z pilota (PPanel).

Ja osobiście nie jestem w stanie określić co komu może być potrzebne.

 

 

Można by co najwyżej rozważyć kombajn all-in-one. Ale też pytanie ile osób będzie chciało to monstrum zassać i odpalić z PENa :)

Odnośnik do komentarza
Udostępnij na innych stronach

  • 1 miesiąc temu...

Witam,

Dzisiaj po restarcie (a dawno nie restartowałem) za nic nie mogłem zmusić do działania swojego VFD wciśniętego do BSKA.

Przejrzałem pliki i znalazłem wpis w /etc/sysconfig/gfunctions, który parsuje /etc/sysctl.conf zamiast /etc/sysconfig/system.conf

 

 

Po zamianie na /etc/sysconfig/system.conf wszystko działa idealnie.

 

 

Nie wiem czy planujecie przejście ze zmiennymi do sysctl.conf czy to po prostu mała pomyłka ;)

 

 

Pozdrawiam!

Odnośnik do komentarza
Udostępnij na innych stronach

Dołącz do dyskusji

Możesz dodać zawartość już teraz a zarejestrować się później. Jeśli posiadasz już konto, zaloguj się aby dodać zawartość za jego pomocą.

Gość
Dodaj odpowiedź do tematu...

×   Wklejono zawartość z formatowaniem.   Usuń formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Odnośnik został automatycznie osadzony.   Przywróć wyświetlanie jako odnośnik

×   Przywrócono poprzednią zawartość.   Wyczyść edytor

×   Nie możesz bezpośrednio wkleić grafiki. Dodaj lub załącz grafiki z adresu URL.

×
×
  • Dodaj nową pozycję...