[devel] Fw: patches, reports and some blablabla

Пн Апр 16 23:42:35 MSD 2001

Hi!
Многое уже исправлено, но все равно посылаю -- письмо
интересное.

Начало пересылаемого письма:

Date: Sun, 15 Apr 2001 20:01:22 +0400
From: Sergei Aranovsky <Sergei.Aranovsky на mtu-net.ru>
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