From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 2 Jan 2004 20:39:31 +0200 From: Michael Shigorin To: devel Message-ID: <20040102183931.GY30690@osdn.org.ua> Mail-Followup-To: devel References: <200312221633.42906.aris@altlinux.ru> <3FF5A963.9060405@altlinux.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WK3l2KTTmXPVedZ6" Content-Disposition: inline In-Reply-To: <3FF5A963.9060405@altlinux.ru> User-Agent: Mutt/1.4.1i Subject: [devel] [POLICY] A-[plugin]->B (was: ladspa-guitar-*) X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.3 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2004 18:39:33 -0000 Archived-At: List-Archive: List-Post: --WK3l2KTTmXPVedZ6 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Fri, Jan 02, 2004 at 08:24:51PM +0300, Mikhail Yakshin wrote: > ladspa_sdk - пакет довольно странно упакован и, по-моему должен быть > разбит и поименован примерно так: > libladspa - /etc/profile.d > libladspa-devel - *.h, все имеющее отношение к сборке и макросы > libladspa-doc - вся документация, возможно, ее можно включить в -devel > libladspa-utils - утилиты типа listplugins, возможно, их можно включить > в libladspa Я бы (с низким приоритетом) высказался за ladspa-common или даже просто ladspa; вынос "всего имеющего отношения к сборке" в какой (lib)?ladspa-devel еще может быть осмыслен -- но вот разносить копеечные утилиты и документацию по отдельным пакетам -- IMCO бессмысленно. В общем, спорим, не подеретесь. :) > Для пакета, видимо, стоит все-таки определить целевую аудиторию > и каким-то образом побить его. Я, конечно, понимаю, что он и > так маленький, но в данном случае речь идет даже не о размере, > а о закладывании базиса для цивилизованной упаковки в пакеты... А цивилизованная упаковка для пакетов по два кило без кошмарных зависимостей бессмысленна. Грузите апельсины бочками, и все тут. > Дальше, сам суффиксы -plugins мне категорически не нравится Даже без множественного числа навешивание *и* префикса, *и* суффикса выглядит действительно чуточку ой. Это да. > Вообще, может быть тут стоит провести некую локальную революцию Это называется cleanup. (в сторону: ну там .la cleanup... ;) > в Сизифе на эту тему и описать такое каким-то образом в > полиси?.. Бесспорно. Не хотите пройтись по e.g. Debian policy [1], существующему ALT Packaging HOWTO [2] и недостающее во втором написать и прислать в docs@ ? Как вариант -- можете подключиться к созданию [3], но это по большей части моя отсебятина. > xmms вот сейчас переходит на префиксную схему, но там, см. > выше, есть из-за чего - там схема "xmms-название", разумеется, > не годится Разумеется, годится. Просто без разделения плагинов по "кучкам" общая куча нарастала как-то совсем неправильно, и это при том, что неопакеченных (и стоящих того) еще есть. При этом для general plugins в результате размышлений и вопросов было оставлено простое наименование "xmms-$plugin": они слишком разношерстные, а субпрефикс "gen-" тут информативности не добавлял. > из-за того, что плагины бывают разные, а еще из-за того, что > есть пакет xmms с его частями -devel и т.п. Строго говоря, libxmms-devel. :) > Нам же по-моему тут вполне можно обойтись "ladspa-название". Если > Было бы здорово, пока плагинов относительно немного, перейти на более > четкую идеологически схему, чем "так повелось". Кстати, пока у темы: есть предложение зафиксировать рекомендацию: При ситуации "исходный пакет A дает подключаемый модуль (плагин) для использования с пакетом B" (модули к xmms, multisync, ...) следует использовать название пакета с таким модулем в виде B-A, т.е. отталкиваясь от "пункта назначения", с целью группирования пакетов по названию около: 1) необходимого; 2) базового; 3) того, "для" которого будет востребована добавляемая функциональность. Если пакет с оригинальным названием существовал (существует) в Sisyphus или широко распространен в виде сторонних сборок, следует добавить в spec-файл тег "Obsoletes: старое_название". При этом несоответствие названия в upstream не должно быть препятствием; например, возможно переименовать imms в xmms-imms или synce-multisync_plugin в multisync-synce. В данном случае это применимо к gstreamer-ladspa / xmms-ladspa. Ура, я не один в этих соображениях :) [1] http://www.debian.org/doc/debian-policy/ [2] http://docs.altlinux.ru/alt/devel/ch01.html [3] http://wiki.atmsk.ru/index.html/AltPolicy -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/ --WK3l2KTTmXPVedZ6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/9brjbsPDprYMm3IRAokKAJ9QtxNSQMVWjMB+t3vlMFaIw9YSjACaA+rc tO4W0KSAd3AuEO38Lzh9UPU= =JpKk -----END PGP SIGNATURE----- --WK3l2KTTmXPVedZ6--