[devel] python vs gcc

[Alexey Tourbin <at@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]

On Sun, Oct 28, 2007 at 08:52:39PM +0400, Peter V. Saveliev wrote:
> (исключая gcc -- там полный набор), лишая разработчика универсальности среды. 
> Сизиф сейчас дружественен пользователю и мэйнтейнеру, но враждебен 
> разработчику.

Полный набор gcc тоже даёт проблемы.  Я сейчас хочу запаковать
статические библиотеки libatlas-devel-static с фортрановским кодом.
Соответствено, я добавил зависимость на libgfortran-devel-static,
но её недостаточно.  Она может быть удовлетворена таким образом,
что gcc всё равно не найдёт libfortran.a.

То есть если мы компилируем другим gcc то зависимость на libgfortran.a
разрешается по-другому, и gcc её не находит.

/usr/lib/gcc/i586-alt-linux/4.1.1/libgfortran.a
/usr/lib/gcc/i586-alt-linux/4.2.0/libgfortran.a

Эта зависимость двусмысленна, потому что ей можно приписать два варианта
разрешения, точнее, интерпретировать её несколькими способами:
1) Должна разрешаться в тот же пакет, с которым был собран
libatlas-devel-static, в данном случае libgfortran4.1-devel-static.
2) Должна динамически разрешаться в тот пакет, который комплементарен
текущей версии /usr/bin/gcc.
3) Должна динамически разрешаться в соответствии с версией
%set_gcc_version.
4) ...

То есть дублирование системных вещей ВСЕГДА привносит какую-то
неопределённость в семантику зависимостей.  Они перестают разрешаться
"как надо" и начинают разрешаться как попало.

С gcc эта проблема возникает редко и стоит не очень остро,
просто потому что gcc это такая вещь в себе и она имеет ограниченное
количество "двусмысленных выплесков" типа libgfortran-devel-static.
Но если речь идёт о базовом системном интерпретаторе, который служит
ОСНОВОЙ для порождения иерархии зависимостей, тогда эта проблема
возникает часто и стоит остро.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]