From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aleksey Novodvorsky To: devel@altlinux.ru Message-Id: <20010416234235.2e8c74fd.aen@logic.ru> X-Mailer: Sylpheed version 0.4.62 (GTK+ 1.2.10; i586-mandrake-linux) Organization: Institute for Logic Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Subject: [devel] Fw: patches, reports and some blablabla Sender: devel-admin@linux.iplabs.ru Errors-To: devel-admin@linux.iplabs.ru X-BeenThere: devel@linux.iplabs.ru X-Mailman-Version: 2.0 Precedence: bulk Reply-To: devel@linux.iplabs.ru List-Help: List-Post: List-Subscribe: , List-Id: IPLabs Linux Team Developers mailing list List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 16 Apr 2001 23:42:35 +0400 Date: Mon, 16 Apr 2001 23:42:35 +0400 Archived-At: List-Archive: List-Post: Hi! Многое уже исправлено, но все равно посылаю -- письмо интересное. Начало пересылаемого письма: Date: Sun, 15 Apr 2001 20:01:22 +0400 From: Sergei Aranovsky To: aen@logic.ru Subject: patches, reports and some blablabla Здравствуйте, Алексей, Предупреждаю, письмо длинное и скучное. Во-первых, патчи (возможно, что-то уже поправили?) в аттаче. 1. WMConf.App валится, если на страничке правки меню (бывшего текстовым, например, после выполнения wmaker.inst) отказаться его конвертировать в property list. 2. Gnucash (import qif account->cancel) == core dump (SIGABRT) Далее. Пробегавший в рассылке патч (кажется, Мараховского) к WMMail не нужен -- количество писем (-1) вызвано неправильными настройками, а вовсе не ошибкой в программировании. Мои настройки WMMail в аттаче, обратите внимание на параметр MailboxHasInternalData. В поставке он установлен в Yes, что неверно (по крайней мере, для того формата mbox, который используется). Во-вторых, замечания. 1. Программа установки, стадия выбора принтера -- случайно её выбрав, отказаться от установки принтера уже нельзя, по крайней мере, походящая кнопочка в диалоге не возникает до последней стадии установки (принтера). Или для этого предполагалось использовать звёздочки слева? 2. Камешек в X. Драйвер Tseng (X 4.0.2) не дружит с FB. Результат - X надо настраивать руками после установки. При этом, если наивный усер попросит, чтобы ему консоль FB предоставили, настройка, понятно, не пройдет. 3. On Laptop (Dell CPi266XT, Neomagic Chipset), Nautilus hangs X v4. Воспроизводится: открыть наутилус, выбрать отображение как музыки. Желательно при этом иметь с машиной telnet соединение, чтобы была возможность отладиться. (Если не воспроизведется, дайте знать, помогу воспроизвести. Или, как вариант, если у Вас есть X и Nautilus, собранные с отладочной информацией, я мог бы попробовать отловить ошибку. Просто собирать X мне не на чем). 4. Было бы неплохо (для лаптопщиков), если бы установки скорости клавиатуры сохранялись при suspend, а при resume восстанавливались. Вариант, который я использую -- в аттаче (keyboard.patch), но там нет сохранения настроек. (как вариант, использовать программу настройки клавиатуры для установки параметров, поскольку способ чтения текущих настроек неясен). 5. GTK+ интерфейс к некоторым программам неряшлив. Возможно, тут виной длина названий эдементов интерфейса на русском, а по умолчанию ширины, скажем, кнопок устанавливаются равными (и равными ширине самой широкой). Особенно отличился в этом плане freeciv client, список городов просто не помещается на экране, а уменьшить нет возможности (эта программа выделяется еще и оригинальным переводом некоторых терминов, право же, лучше непереведённый интерфейс, чем переведённый так). Как Вы полагаете, не лучше ли было бы в тех случаях когда у программы есть и Афиновский, и GTK+ный, и, скажем, Мотифовский интерфейсы, оставлять Афиновский или Мотиф. Преимущества GTK+ в ряде случаев неочевидны, а внешний вид (в отсутствие тем) довольно жалкий (на мой вкус). 6. rpmdrake в отсутствие supermount. Просит вставить второй cdrom. На то, чтобы размонтировать и вытолкнуть первый, искусственного интеллекта хватает :-), а вот понять, что вставленный надо бы смонтировать -- тут увы... 7. настройка имени хоста и домена не отразилась на настройках dhcpd - как было homelan.org, так и осталось. В третьих, мне бы хотелось (если я еще Вас не утомил), высказать некоторое сожаление тенденциями в пакетировании и планировании зависимостей пакетов. Я в этом не одинок, раздражённое письмо одного из подписчиков рассылки тому свидетельством. Тенденция такова, что (для облегчения ли себе работы, или по небрежности, или по каким-то мне недоступным соображениям) составители укрупняют пакеты. В результате копеечная утилита тянет за собой несколько попутных мегабайтов (в лучшем случае), которые будут лежать мертвым грузом. В некоторых случаях это вызвано особенностями оригинальных пакетов (как, например, KDE) или особенностями применённых для построения программы средств (я не использую перл, но приходится терпеть его на диске, поскольку он неявно требуется каким-то средствам настройки). Но, к сожалению, все это усугубляется образующимися вторичными зависимостями. Возмем, скажем, xscreensaver. Пакет xscreensaver требует массу гномьих библиотек, которые на самом деле программе xscreensaver не нужны -- причиной (если я не прав, поправьте) включенные в пакет настройки для Gnome Control Center. Замечу, что лежащий рядом xscreensaver-gl гнома не требует, хотя настройки для control center он тоже содержит. Мне кажется, что такой подход к составлению пакетов даст печальные результаты. И без того некогда маленький и шустрый линукс еле ворочается под кучей барахла, которую ему приходится тащить. Поэтому, мне кажется. имело бы смысл дробить пакеты. Скажем, тот же xscreensaver распался бы на три пакета: 1. собственно xscreensaver (с минимальными зависимостями) 2. настройки для gnome (зависящий от gnome и xscreensaver и входящий в группу пакетов gnome) 3. настройки для KDE (зависимости аналогичные). Подобное деление подошло бы и к некоторым другим пакетам. Что касается самих гнома и КДЕ, для них тоже бы подошло более мелкое деление. Разумеется, мелкое деление на пакеты усложнит работу составителей, но ведь часть отслеживания зависимостей можно автоматизировать (например, поиск библиотек). Было бы замечательно, если бы Вы или кто-то из Ваших коллег высказал официальную точку зрения ALT на эту проблему (например, в рассылке, или на сайте, или частным письмом, если Вы найдете это заслуживающим переписки). С уважением, Сергей Арановский _______________________________________________ Devel mailing list Devel@linux.iplabs.ru http://www.logic.ru/mailman/listinfo/devel