[devel] Эссе о lib%name-devel :)

[Mikhail Zabaluev]

Доброго времени суток.

Считаю нужным обстоятельно высказаться на столь активно обсуждаемую
тему, хотя бы потому, чтобы разъяснить, за что я так взъелся по,
казалось бы, пустяковому вопросу.

Вы правы, поезд ушел и с delibification не стоит торопиться накануне
релиза.  Но я хочу показать, почему принятое сейчас правило может быть
неудобным и недружественным к пользователю. О логичности спорить
не будем, потому что логика в правиле все же есть. Я буду обозначать
принятую в нашем дистрибутиве конвенцию lib%name-devel "правилом
ALTLinux", а конвенцию %name-devel -- "правилом RedHat".

Итак, рассмотрим достаточно типичный сценарий поведения пользователя,
который, судя по сообщениям в рассылки, встречается довольно часто.

1. Пользователь много слышал о софте по имени foo, видел ссылки на
freshmeat'е и горит желанием эту штуку поставить. Он находит пакет foo
в дистрибутиве и радостно его устанавливает. По пути выясняется, что
пакет foo требует libfoo. Пользователь, недолго думая, удовлетворяет
зависимость, либо это за него делает автоматика. Факт наличия libfoo
быстро выветривается из памяти пользователя.

2. Спустя некоторое время пользователь решает собрать нечто с
использованием foo. Собирает он не из source RPM, поэтому никаких
BuildRequires не существует. Пользователю быстро становится ясно, что
для разработки нужны некие дополнительные файлы. Если он знаком с
RedHat и не ведает подвоха, он ищет foo-devel и, не найдя, приходит в
горькое недоумение. Если пользователь стреляный, он будет искать и
libfoo-devel и foo-devel (поскольку второй вариант тоже
встречается). Понятно, что цена вопроса -- один glob, но в гуевых
средствах этот glob придется делать вручную :( Поиск еще усложняется,
когда lib-пакеты меняют "корень" по имени библиотеки, которую
они содержат -- что, кстати, правильно для пакета с самой библиотекой,
по тем же соображениям легкости поиска. Когда от вас требуют
libcapplet.so.0, вы первым делом станете искать пакет libcapplet.
Но чтобы догадаться, что для разработки под control-center нужен
libcapplet-devel, нужно обладать инсайдерской информацией :)

С "правилом RH" проблема часто решается еще на этапе 1, когда
пользователь видит в листинге foo и foo-devel рядом и устанавливает их
вместе "до кучи". Так было и в Spring.

Были возражения, что в дистрибутиве с "правилом RH" не однозначно
выводится имя -devel пакета из имени libfoo. Во-первых, эта
неоднозначность симметрична описанной выше для "правила AltLinux".
Во-вторых, ниже приведена shell-функция, которая выдает имя
соответствующего -devel по имени _любого_ пакета, если действует
"правило RH".

FindDevel() {
	local name=$1

	# Try the obvious
	local develname="${name}-devel"
	if CheckPackage $develname; then
		echo $develname
		return
	fi

	# Deduce from the name of the source package
	local srcname=$(rpm -q --qf='%{SOURCERPM}\n' $name)
	develname=${srcname%%-[0-9]*}-devel
	if CheckPackage $develname; then
		echo $develname
		return
	fi

	return 1
}

Не приведенная здесь функция CheckPackage проверяет наличие пакета в
репозитарии. Теперь попробуйте-ка вычислить libcapplet-devel из
control-center по "правилу AltLinux" без доступа к spec'у.

И еще. Будет ли 'apt-get install libfoo-devel' устанавливать foo-devel,
если у того прописан соответствующий Provides? Если да, то можно
обязать в -devel писать Provides: lib%name-devel для всех пакетов
lib%name, которые данный -devel покрывает. Тогда, имея libfoo, можно
будет не думая набрать приведенную выше команду и получить ровно то,
что нужно.

-- 
Stay tuned,
  MhZ                                     JID: mookid на jabber.org
___________
God is Dead.
		-- Nietzsche
Nietzsche is Dead.
		-- God
Nietzsche is God.
		-- Dead
_______________________________________________
Devel mailing list
Devel на linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel