Po co te backslashe w specu?

[Tomasz Pala]

On Wed, Dec 28, 2016 at 08:42:16 +0100, Jan Rękorajski wrote:

>> Dnia środa, 28 grudnia 2016 00:56:24 Łukasz Maśko pisze:
>> > Chodzi o VirtualBox.spec. Po co ta nawała znaków '\' w ostatniej wersji tego
>> > speca? Przez to popsute są np. skrypty %post.
[...]
>>    1:VirtualBox-gui         ########################################### [100%]
>> /var/tmp/rpm-tmp.14648[17]: \: not found
[...]
> Naprawione. rel 2 juz pociągnie poprawny skrypt.

Nie mogę w swoim lokalnym repo znaleźć źródła akurat 3 backslashy, więc
pewnie po prostu coś zrobiłem źle. Ale to znaczy, że od 10 dni lądują
pakiety z tym błędem.

Czy nie powinniśmy tych makr przerzucić wprost do plików wykonywalnych
wołanych ze speca? Choćby nawet do jednego pliku, któremu jako parametr
podaje się funkcję, jaką ma wykonać? Zaszywanie skryptów w samym specu
daje możliwość zainstalowania pakietów w 'obcym' systemie, niby fajnie,
ale równie dobrze nasze pakiety mogłyby wymagać rpm-pld-macros
zawierającego odpowiedni skrypt/zestaw skryptów. Kolejna zaleta (poza
brakiem konieczności przebudowywania pakietów z okazji np. j.w.) to
możliwość manipulacji przez administratora systemu. Przy okazji byłyby
jasno rozdzielone build-macros od package/system-macros. Bo w tej chwili
- kto mi powie, czy gconf_schema_install oraz glib_compile_schemas są
wykorzystywane przy budowaniu czy instalowaniu pakietu?

Zresztą już obecnie są 4 makra wołających /usr/lib/rpm/user_group.sh
z rpm-base - to się niekoniecznie powiedzie na 'obcym' systemie.

Ułatwiłoby to zdecydowanie zarówno pisanie/debugowanie (zwykły skrypt, a
nie taki escape'owany), a przy okazji ułatwiło nanoszenie poprawek - bo
w obecnym układzie nie mam pewności, że w markach %systemd* też nie
zostały jakieś moje błędy.


Tam, gdzie makra coś jeszcze robią (widzę np. jakieś z debugiem), można
pozostawić istniejące makra, a jedynie kazać im wołać odpowiednią binarkę.

W każdym razie obecny śmietnik trzyma nas gdzieś dekadę wstecz.

-- 
Tomasz Pala <gotar at pld-linux.org>