Których pakietów nie przerzucać?

[Jacek Konieczny]

On Sun, Jan 11, 2004 at 06:07:57PM +0100, Jakub Bogusz wrote:
> > Dla _noauto*files chyba nie. Gdzie indziej mogę dodać, o ile nie będzie
> > to wymagać zależności od jakiejś dodatkowej biblioteki.
> 
> regex.h z glibc by wystarczyło.

Już znalazłem.

> > IMHO w
> > większości przypadków globy starczją().
> 
> Dla tego co jest teraz w specach starczają - ale popsułoby to ich
> kompatybilność między wersjami rpm-a (inne dla <= 4.3-0.2003xxxx, inne
> dla 4.3-0.2004xxxx).

No to może rzeczywiście warto na regexpy to pozmieniać. Ale to trochę
roboty by było (fnmatch() jest znacznie prostrzy w użyciu) i na prawdę
nie jestem pewien czy jest to tego warte. Stary RPM i tak złe pakiety
robić będzie (bo bez kolorów i bez zależności per-plik), więc może
lepiej nie trzymać kompatybilności na siłę.

Ale też doszedłem do wniosku, że czasami regexpy mogły by być przydatne,
nawet do _noautoreqfiles - żeby opuścić przetwarzanie zależności dla
całych drzew katalogów.

> > Zastanawiam się tylko czy generowanie zawsze zalezności w skryptach jest
> > rzeczywiście złe? IMHO poiwnno zostać, tylko trzebaby je tak zrobić,
> > żeby nie robiło złych zależności.
> 
> Kiedyś już było omawiane - na pewno dla php/peara w większości było to
> niechciane zachowanie (działa dobrze tylko dla rzeczy pearowych,
> w zwykłych php potrafiło generować bezsensowne Provides/Requires).

To rzeczywiście zależności PHP można by włączac per-spec. Wystarczyłoby
w nich definiowac makra __php_requires i __php_provides.

> Dla perla by dużo złego nie zrobiło (trzeba by było dodać _noauto* do
> kilku czy kilkunastu pakietów - gorzej z namierzeniem takich) - ale
> znowu pojawiłaby się niespójność - z zachowaniem dla peara i z tym, co
> było kiedyś (spece są dostosowane do starego zachowania, jest %include
> macros.perl w ponad tysiącu speców tego wymagających).

To i tak było do wywalenia. I AFAIR właściwie nic nie robiło.

Niestety okazało się że dzisiaj nie dam rady tego RPMa zrobić, więc jak 
chcesz, to możesz podłubać. Ja mogę jutro w pracy spróbować.

Do zrobienia jest przede wszystkim _noautoreq i _noautoprov, ale wygląda
na to że to będzie dość trudne do zrobienia. Nie wiem jak bezpiecznie
usuwać wygenerowane zależności w RPMie, więc musiałbym warunkiem obłożyć
każde ich dodawanie.

Pozdrowienia,
        Jacek