Bug 7393

Summary:	Добавить возможность выбора subfs\|обычные записи в fstab
Product:	Sisyphus	Reporter:	Eugene Vlasov <eugvv>
Component:	hal	Assignee:	Anton Farygin <rider>
Status:	CLOSED NOTABUG	QA Contact:	qa-sisyphus
Severity:	enhancement
Priority:	P3	CC:	eostapets, mike
Version:	unstable
Hardware:	all
OS:	Linux

Description Eugene Vlasov 2005-07-19 11:41:13 MSD

В hal-0.5.3-alt2 в fstab по умолчанию добавляются записи с типом файловой
системы subfs. Хотелось бы иметь возможность выбора - subfs или обычные записи в
fstab (vfat, iso9660...). Например сделать два комплекта настроек, один
упаковать в пакет hal-config-subfs а второй - в hal-config-traditional. Или
переключать конфиги при помощи альтернатив.
Я понимаю, что можно написать под себя свой конфиг (я в конечном счете так и
сделал), но уж больно у него конфиги тяжелые. Особенно учитывая недостаток
документации в пакете.

Comment 1 Anton Farygin 2005-07-19 12:23:59 MSD

Никто не запрещает запаковать отдельный пакет, изменяющий поведение hal

Comment 2 Eugene Vlasov 2005-07-19 12:51:53 MSD

Что-то у меня не получилось при помощи отдельного конфига убрать опции
монтирования "fs=cdfss|vfat". Пришлось убирать это из
/usr/share/hal/fdi/policy/10osvendor/10-storage-policy.fdi.
Документация с freedesktop.org не помогла.

Comment 3 Anton Farygin 2005-07-19 13:10:54 MSD

В исходниках обнаружено свойство <remove>

Например:
<remove key="volume.policy.mount_option.fs" type="string"/>

type указывать обязательно.
Работает только внутри device и match

Comment 4 Michael Shigorin 2005-07-19 16:48:10 MSD

(In reply to comment #1)
> Никто не запрещает запаковать отдельный пакет, изменяющий поведение hal
control(8)?

2 eugvv: возможно, самый логичный вариант. :)

Comment 5 Anton Farygin 2005-07-20 13:57:59 MSD

control - самый нелогичный вариант.

тем более если он будет что-то править в /usr/share/ (файлы не помечены как
config, и не будут помечены)

Comment 6 Eugene Ostapets 2005-07-20 15:04:58 MSD

На самом деле нужна схема минимального неизменяемого справочника в /usr/share и
рабочие конфиги в /etc, которые могу в том числе и модифицироваться с помощью
альтернатив или control

Comment 7 Anton Farygin 2005-07-20 15:55:36 MSD

не вижу смысла в control для hal

проще сделать конфигуратор

а рабочие конфиги в /etc лучше не класть - авторы hal имеют свойство менять его
поведение.

Comment 8 Eugene Ostapets 2005-07-20 16:35:13 MSD

Смена поведения штука, конечно, хорошая, но заставлять пользователя править
конфиги в /usr/share тоже не лучший выход.

А control можно использовать просто как очень удобный механизм переключения
альтернатив наподобии select-gcc

Comment 9 Anton Farygin 2005-07-20 16:42:52 MSD

А зачем для смены поведения править конфиги в /usr/share ?

Достаточно положить перекрывающий конфиг в /etc/hal

Comment 10 Eugene Ostapets 2005-07-20 18:14:12 MSD

Сколько пользователей в процентном отношении будут создавать собственный конфиг,
в котором сначала нужно почитав документацию написать правила удаления старых
правил, а затем добавить новые правила? Я думаю < 1%...

Если же в /usr/share положить только конфиги не предполагающие правки или
перекрытия для 90%, а остально положить в /etc/hal, то какой бы вариант
настройки не выбрал пользователь - плохой привычки у него не возникнет...

А так меня советы из серии vim /usr/share/hal/...fdi напрягают очень сильно -
такого не должно быть в нормальном дистрибутиве!

Comment 11 Anton Farygin 2005-08-04 18:08:00 MSD

именно. Поэтому я и говорю, что достаточно:
или написать модуль к альтератору
или запаковать готовые конфиги в пакет.
но эти оба пункта явно не ко мне, текущее поведение считаю правильным и
обоснованным.