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

[Tomasz Pala]

On Mon, Feb 06, 2012 at 16:25:02 +0100, Paweł Gołaszewski wrote:

>> 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:)
> 
> 2/3 ;)

Sam powiedziałeś, że połowa;)

> A to jest raczej kwestia założeń (RM?).
> - podstawowy jest SysV i systemd jest tylko dodatkiem do niego
> - podstawowy jest systemd i SysV jest tylko dodatkiem do niego
> - oba są równoprawne i wymienne.
> 
> Ja zakładam opcję "3", bo dla mnie inaczej nie ma to sensu, ty zakładasz 
> wersję "1".

No ej, ja sam cisnąłem systemd:) Chwilowo z braku czasu nie zaglądam w
pakiety, ale oczywiście fajnie byłoby mieć pełne wsparcie dla
wszystkiego. Niemniej jednak zdaję sobie sprawę z tego, że systemd z
sysconfiga bierze wyłącznie środowisko.

>> Nawet do serwera tacacs?
> 
> Co masz do tacacs-a? Akurat jego używam :P

Tego z tacacs.spec? No kiedyś pamiętam, że coś w nim grzebałem, nawet
swoje commity widzę, i widzę że nawet tego na buildery nie puściłem;) Bo
ten z tac_plus to straszny zabytek jest.

> ...fajnie by było mieć systemd działające "the Right Way".
> Zgadzam się, ale pytanie podstawowe: co TERAZ mamy osiągnąć? Jak dla mnie 

Myślę, że na teraz to potrzebujemy reguł postępowania. Większość udało
się już wypracować (np. R w pakietach, triggery i makra RPM-a), ale np.
nie wiem, czy ktoś coś zaglądał do logrotate? To co ja ostatnio miałem,
to rotacja logów robiła service reload, co nie zadziała dla systemdowych
unitów (nasz SysV napisze, że usługa nie jest włączona i podziękuje).

>> co później? Pakiet wylatuje z PLD?
> 
> Wylatuje systemd z niego.
> Jak już pisałem - porządki zrobię.

No to mi nie przeszkadza _tymczasowy_ unit uruchamiający SysV - ale decyzja RM-a.

-- 
Tomasz Pala <gotar w pld-linux.org>