Jakie BR-y dodawać do speców?

[Tomasz Pala]

On Mon, Aug 01, 2011 at 13:15:57 +0200, Bartosz Świątek wrote:

> Zatem parę przykładów:

Anno domini 5 lat temu.

> date: 2005/12/27 10:07:59;  author: twittner;  state: Exp;  lines: +4 -2;
> - remove redundant BR: ruby-modules (BR: ruby-devel implies it)

Na tej samej zasadzie nie dodajemy BR: cośtam-libs mając cośtam-devel,
bo to nie jest zależność od _innych_ bibliotek, lecz kwestia naszego
podziału.

> date: 2000/05/01 21:02:35;  author: mkochano;  state: Exp;  lines: +7
> -2;  kopt: kv;
> - Removed 'BuildRequires: (XFree86|glib)-devel' from packages which have
>   'BuildRequires: gtk+-devel'. They were redundant, beacuse 'gtk+-devel' says
>   what it needs using 'Requires'. BTW, awk rules :)

To jest błąd - ale o tym przekonasz się niżej.

> date: 2003/10/12 12:27:06;  author: qboosh;  state: Exp;  lines: +10
> -8;  kopt: kv;
> - removed redundant python deps (BR python 2.2 + pyrequires_eq is enough)
                                                   ^^^^^^^^^^^^^
Rozumiem, że wziąłeś losowe linijki zawierające słowo 'redundant' (a
nazwy speca nie dałeś, żeby przypadkiem tego nie sprawdzić)?

> date: 2003/08/23 01:51:34;  author: twittner;  state: Exp;  lines: +8 -10;
>  - removed redundant Requires: /bin/awk (rc-scripts contains it).

To jest R, a mówimy o BR. Tak samo jak pewną grupę ścisłych zależności
BR mamy dopisane od razu do rpm-build (o czym wspominałem), tak pewne
zależności (nieautomagiczne) istnieją w rc-scripts.

Czyli na 4 przykłady znalazłeś 3 nie na temat oraz 1 błąd. Popisujesz
się...

> I takich przykładów jest sporo. Tylko nie mów mi, że to bzdury i
> jakieś starocie.

A co mam powiedzieć?, że nie rozumiesz, co się do ciebie pisze i
próbujesz znaleźć jakieś przykłady, jakby to one miały być niby
wyrocznią? Jeśli mi nie wierzysz, to przeczytaj co napisał Arek.

> Wyobraź sobie, że ktoś wpada na genialny pomysł
> usunięcia z rc-scripts wywołań awk to będziesz musiał wszędzie awk
> dopisywać jako BR.

Wyobraź sobie, że pewne R (nie BR, rozróżniaj tak fundamentalne kwestie)
były w zamierzchłych czasach celowo na zasadach umownych pominięte i
nikt ich z rc-scripts nie ma prawa usunąć, tak samo jak z rpm-build
nigdy nie wyleci glibc-devel (modulo zmiana nazwy pakietu czy przejście
na jakiegoś forka), mimo że mógłbyś się upierać, iż część pakietów wcale
glibca nie wymaga do zbudowania.

> Tak samo cuda z xorg-* albo tak jak z qt4 albo kde4.

No właśnie - to teraz zajrzyj w dowolny pakiet wymagający GTK+2 i
sprawdź, czy przypadkiem nie wymaga również jakiegoś xorg-lib-*-devel.

> I wyobraź też sobie, że RM Th sam grzebie w tych paczkach, które nota
> bene miały pół roku temu usuwane takie powtarzające się BRy, bo np.
> kde4-kdelibs-devel ich już wymagał, a one wymagały m.in. też
> kde4-kdelibs. I jakoś było i jest to tolerowane.

Aha, bo kde4-kdelibs i kde4-kdelibs to są inne liby.

> Jak praktyka wygląda to Ci właśnie pokazałem. A teraz Ty mi pokaż
> jakiś zapis w zasadach developowania, który potwierdzi Twoją teorię.
> Zobaczymy teraz kto się ośmieszy.

Takie pierwsze z brzegu popularne pakiety (twoim sposobem, bo przecież
doskonale wiesz, że nigdzie nie są spisywane tak oczywiste zasady):

~:  rpm -qpR gtk+2-devel-2.24.5-1.i686.rpm | grep xorg-lib-libX.\*-devel
warning: gtk+2-devel-2.24.5-1.i686.rpm: Header V4 DSA signature: NOKEY, key ID e4f1bc2d
xorg-lib-libX11-devel
xorg-lib-libXcomposite-devel
xorg-lib-libXcursor-devel
xorg-lib-libXdamage-devel
xorg-lib-libXext-devel
xorg-lib-libXfixes-devel
xorg-lib-libXft-devel
xorg-lib-libXi-devel
xorg-lib-libXinerama-devel
xorg-lib-libXrandr-devel >= 1.3.0
xorg-lib-libXrender-devel

gimp.spec
BuildRequires:  gtk+2-devel >= 2:2.12.
BuildRequires:  xorg-lib-libXext-devel
BuildRequires:  xorg-lib-libXfixes-devel

inkscape.spec
BuildRequires:  gtk+2-devel >= 2:2.14.0
%{?with_xft:BuildRequires:      xorg-lib-libXft-devel}

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