SPECS: users.spec (HEAD)

[Andrzej Krzysztofowicz]

> > Log message:
> > - translations; are all these packages necessary?
> 
> Zastanawiam się czy to jest wogóle właściwy sposób "obsługi" grup. Jakieś 
> to przerośnięte... %pre/%post w pakietach są z kolei cholernie 
> skomplikowane i niedoskonałe... Prawdę mówiąc średnio mam pomysł na to jak 
> ten problem rozwiązać. Może rpm powinien rejestrować użytkowników w swojej 
> bazie? Wtedy byłoby, że dany pakiet wymaga usera o jakiejś-tam nazwie. 
> Teraz: powstałby pakiet rpm-users, który posiadałby w sobie *definicje* 
> userów (uid, gid, .....). Przy instalacji pakietu tworzony byłby na 
> żądanie user.
> 
> To nawet teraz jest do realizacji w dosyć prosty sposób. Skrypt z bazą 
> działające w ten sposób:
> - %pre sprawdzamy czy baza danych zawiera usera. Jeżeli nie to wyskakujemy
>   z instalacji. To można pominąć dodając do pakietu rpm-users np.:  
>   Provides: rpm-user(http), ale sprawdzenie czy user nie ma innych 
>   danych niż w bazie musi być na tym etapie
> - %post (?) jest wywołanie skryptu, np. rpm-createuser http. W przypadku
>   niepowodzenia... nie wiem co miałoby zwracać.
> - usuwanie byłoby bardzo proste - w %post byłby wołane usunięcie usera np: 
> rpm-removeuser http. Jeżeli coś wymaga tego usera - po prostu nie byłoby 
                        ^^^^^^^^^^^^^^^^^^^^^^^^^
> usuwania

MSZ metoda wykluczona w Ra.
W jaki sposob sprawdzisz, zaleznosci ze skryptu %post? Baza jest chyba
zablokowana, wiec rpm-a nie wywolasz.

Druga sprawa, to kolejnosc wolania skryptow w sytuacji, gdy wymieniamy
jeden pakiet wymagajacy danego usera na drugi wymagajacy tego samego usera.

> Zalety:
> - rozwiązane całe zabawy z %pre/%post, które się rozrastają
> - byłoby to znacznie pewniejsze
> - baza userów mogłaby być nawet %config (ale raczej wolałbym nie, bo jest
>   problem przy upgrade), żeby umożliwić adminowi zmiany danych.

Raczej %ghost, jesli juz.

> - nieużywani userzy - skrypt/program mógłby mieć opcję sprawdzania którzy
>   userzy są już nieużywani. Wręcz to nawet dałoby się załatwić samym
>   rpm-em.
> 
> Wady:
> - prawdę mówiąc nie przychodzą mi do głowy... może poza tym, że to
>   należałoby napisać ;)


-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry w mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Gdansk University of Technology