packages: acpid/acpid.spec, acpid/acpid.service (NEW) - rel.6 - systemd

[Tomasz Pala]

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 <gotar w pld-linux.org>