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

[Paweł Gołaszewski]

On Mon, 6 Feb 2012, Tomasz Pala wrote:
> >> To jest bardzo złe rozwiązanie bo w ten sposób ukrywasz brak wsparcia 
> >> dla systemd.
> > Nic nie ukrywam.
> Z punktu widzenia end-usera uruchamia się natywny unit systemd...

grep service /lib/systemd/system/*

> >> Poza tym systemd ma pewne oczekiwania wobec serwisów, których skrypt 
> >> init.d raczej nie spełnia.
> > Jakie?
> Jest cała instrukcja, jak powinien zachowywać się demon systemdowy. 
> Jeśli tak nie robi, to są przeróżne flagi do unitów systemd (np. oneshot 
> itp.) - tutaj może chodzić o lokalizację PID-ów, locków itp. Celem tego 
> wszystkiego jest zunifikowanie zachowania się tego typu usług.

Type=forking

To wszystko.

> >> Innymi słowy - jak coś robić to porządnie.
> > Fajnie - ale zobacz sobie na cronie dla przykładu. Jest porządnie 
> > zrobione? Guzik - połowa rzeczy, która była dawniej obsługiwana 
> > zniknęła.
> 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

Temat był na tyle nieistotny, że nie pisałem o tym, ale to nie jest 
kierunek, w którym chciałbym iść.

> > Poza tym - na tą chwilę myślę, że ważniejsze jest przeniesienie 
> > serwisów na systemd, bez utraty funkcjonalności. Jak będą przeniesione 
> > to dalej można się bawić.
> Nie wiem, czy przeniesienie wszystkiego na systemd jest aż tak ważne. Z 
> czasem powinny się pojawyć natywne unity do każdej usługi, a jeśli nie 
> to będą takie w innych dystrybucjach.

A psucie _po_ _cichu_ działających instalacji to dobra rzecz?

Oczywiście, że trzeba zrobić przegląd po kolei funkcjonalność w KAŻDYM z 
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.

Arek chce mieć rozgrzebane wszystko póki się ktoś nie zlituje, ale to IMO 
bez sensu.

Lepiej by było zrobić tak:
- do wszystkiego hurtem robimy .service czy co dany usługa wymaga.
- próbujemy uruchamiać to natywnie, z _zachowaniem_ funkjonalności.
- jeżeli się nie da - przez /bin/service.
- 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).
- po zakończeniu akcji "przechodzimy na systemd" jest akcja "czyścimy 
  *service"
- jeżeli z jakichś skryptów znika funkcjonalność - MUSI to być ogłoszone 
  przynajmniej na listach...
- 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...

Mogę się podjąć czyszczenia po wyznaczonej dacie.

-- 
pozdr.  Paweł Gołaszewski          jid:blues<at>jabber<dot>gda<dot>pl
--------------------------------------------------------------------------
If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby
Pro-Logic Surround Sound with Bass Boost and all the music is free.