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

[Paweł Gołaszewski]

On Mon, 6 Feb 2012, Tomasz Pala 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?
> 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 ;)

Choćby i 1/20 to jak akurat jej używasz i są z tego tytułu problemu to 
jest conajmniej wkurzenie...

> > 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.

Przynajmniej trigger musi się w takiej sytuacji pojawić, przerabiający 
obecne opcje. Ale to nie dyskusja na ten moment.

> > 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).

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".

A jaką wersję realizujemy tak naprawdę? RM?

> > Lepiej by było zrobić tak:
> > - do wszystkiego hurtem robimy .service czy co dany usługa wymaga.
> Nawet do serwera tacacs?

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

> Czy pierdyliona rzeczy, które mamy w repo, a nawet się nie budują i nikt 
> ich w PLD nie używa?

Jak się nie budują to i tak przy najbliższej okazji wylecą z ftp-a.

> > - 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...

...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 
pierwszym krokiem jest przejście na startowanie przez systemd i jego 
service (whatever)  wszystkich serwisów dla chętnych na systemd. Z samym 
tym jest wystarczająco dużo roboty.

> > - 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?

Wylatuje systemd z niego.
Jak już pisałem - porządki zrobię.

> I _jak_ naprawisz tego cronie?

Nie ja go popsułem, nie ja go będę naprawiał :P

> Triggerem, który to co jest w service start zrobi bezpośrednio w 
> sysconfig?

To naprawdę osobny wątek i nie chciałbym w to _teraz_ wchodzić, bo się 
zagrzebiemy. Można do tego podejść na kilka sposobów.

> Może po prostu wrzucać unit.service, ale bez aktywowania go?

Nie, to jest bez sensu. Dyskutowaliśmy już na ten temat.

-- 
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.