Obsoletes czy nie obsoletes

[Radoslaw Zielinski]

Paweł Gołaszewski <blues at ds.pg.gda.pl> [21-08-2003 22:28]:
[...]
> On Sat, 16 Aug 2003, Radoslaw Zielinski wrote:
[...]
>> [1] Kloczek napisał w którymś mailu, że robienie dystrybucji to także
>>     w pewnym stopniu kształtowanie przyzwyczajeń.  Coś w tym jest.
> :)
> Cytowanie kloczka ostatnio staje się modne ;)

Czniam uprzedzenia.  Kto dobrze gada, dać wódki.  Kto źle, w kufę dać.

[...]
>> Międzymordź: /usr/lib/rpm/<cośtam>, uruchamiany w dwóch trybach,
>> rejestrowania i wyrejestrowywania;
> Nie wiem czy nie powinna powstać 3 tryb, czyli check - sprawdzanie 
> nieużywanych userów.

I czy uid/gid zgadza się z bazą.  Też o tym myślałem, ale to już
wisienka na torcie.

[...]
> hhhmmm....
> Zastanawiam się czy jednak to nie powinna być gotowa baza userów z 
> osobnego pakietu (jakieś rpm-usersdb). Wydaje mi się, że tak będzie 
> lepiej, w specu będzie tylko np.:
> <cośtam> -U -u http -s apache
> Będzie to rejestrowało użytkownika.

> Całe dane usera będą w bazie usersdb, np. /usr/lib/rpm/(users|group).db. 
> Zmiana usera to będzie jedna korekta w bazie, a nie dłubanie we wszystkich 
> specach.

Racja.

Dodatkowo, łatwiej będzie wymuszać aktualizacje takiego małego pakietu,
jeśli coś spaprzemy (a spaprzemy :-).

Aha: i czy bazy userów / grup nie powinny być połączone?  Z jednej
strony, dobrze byłoby usuwać zbędne grupy.  Z drugiej, nieładnie usuwać,
jeśli admin założył grupę ,,z ręki''.  W sumie, dotyczy to też userów...
Co jeśli założony user/grupa ma inny uid/gid?  Do przemyślenia.

> Teraz pytanie - jak takie rozwiązanie zachowa się w praktyce? Mam na
> myśli sytuację np.: wymiana http z jednego na drugi.

Z punktu widzenia rpm-a, taka sytuacja nie istnieje (tzn. IMO nie
powinna).  Instalujemy drugi httpd, user jest przypisany do obu,
wyrzucamy pierwszy, user nadal ma ,,przydział''.  Nie widzę problemów.

-- 
Radosław Zieliński <radek at karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-pl/attachments/20030822/0c99646e/attachment.sig>