On Mon, Feb 06, 2012 at 14:52:28 +0100, Paweł Gołaszewski wrote: >> Tam są dwie zmienne, znaczy jedna teraz nie działa? ;) > > trzy, z czego dwie nie działały, a na jednej polegałem. > Sam się wściekałeś na psucie działających instalacji, a tutaj ci pasuje? > :P
Oczywiście, że nie. Tak tylko się śmieję z relatywizmu, że brzmiąca groźno 'niedziałająca połowa' to niedziałające 2 opcje:) > A psucie _po_ _cichu_ działających instalacji to dobra rzecz? Nie. Pytanie jak to rozwiązują inni. Najprostsze rozwiązanie to oczywiście zmiana w sysconfig polegająca na tym, że zamiast naszej autorskiej zmiennej (ZROB_COS) stawiamy admina przed koniecznością wpisania wprost (-X blabla -y +Z). Zaletą skryptów SysV była możliwość parsowania opcji i robienia różnych cudów automagicznie, pytanie czy taka funkcjonalność jest warta stosowania opcji PLD-specific. > tych skryptów, ogłosić co wylatuje, etc, etc. Tak według mnie priorytetem > jest teraz przejście na systemd _bez_ niszczenia tego co obecnie działa. No to tu jest po prostu różnica podejścia. Mi się cały czas wydaje, że systemd jest opcjonalne i nie musimy mieć unitów do wszystkiego, CHYBA ŻE faktycznie odpalane przez SysV coś się komuś psuje (i wtedy ten ktoś dorabia porządnego unita, choćby targając gdzieś z neta). > Lepiej by było zrobić tak: > - do wszystkiego hurtem robimy .service czy co dany usługa wymaga. Nawet do serwera tacacs? Czy pierdyliona rzeczy, które mamy w repo, a nawet się nie budują i nikt ich w PLD nie używa? > - próbujemy uruchamiać to natywnie, z _zachowaniem_ funkjonalności. > - jeżeli się nie da - przez /bin/service. Parsowania zmiennych i robienia z nich opcji systemd nie zrobi (a do tego się sprowadza 'jeżeli się nie da'). Co z tym zrobić, nie mam zdania - z jednej strony np. interfejsy podnoszone są przez ifup, z drugiej... > - WSZYSTKIE, które korzystają z /bin/service lądują na odpowiedniej liście > w repo i są dopuszczone do użytkowania do jakiejś daty (powiedzmy - > 30.06.2012). ...no właśnie, z drugiej taki wymóg wg mnie nie ma racji bytu w PLD. A co później? Pakiet wylatuje z PLD? I _jak_ naprawisz tego cronie? Triggerem, który to co jest w service start zrobi bezpośrednio w sysconfig? Może po prostu wrzucać unit.service, ale bez aktywowania go? > - wszystkie paczki, które nie spełnią wymagań do daty - wylatuje z nich > support systemd. Poza BARDZO uzasadnionymi przypadkami, jak mysql, bo > tutaj będzie bardzo dużo roboty z reimplementacją tego co mamy > zrobione... Ja też mam swojego SysV np. do greenpluma, który jest wielokrotnie bardziej złożony. Nie wiem co tam w mysql siedzi, ale to pewnie można zrobić jako template i triggerem jednorazoro podpiąć wszystkie clustry. -- Tomasz Pala <[email protected]> _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
