В hal-0.5.3-alt2 в fstab по умолчанию добавляются записи с типом файловой системы subfs. Хотелось бы иметь возможность выбора - subfs или обычные записи в fstab (vfat, iso9660...). Например сделать два комплекта настроек, один упаковать в пакет hal-config-subfs а второй - в hal-config-traditional. Или переключать конфиги при помощи альтернатив. Я понимаю, что можно написать под себя свой конфиг (я в конечном счете так и сделал), но уж больно у него конфиги тяжелые. Особенно учитывая недостаток документации в пакете.
Никто не запрещает запаковать отдельный пакет, изменяющий поведение hal
Что-то у меня не получилось при помощи отдельного конфига убрать опции монтирования "fs=cdfss|vfat". Пришлось убирать это из /usr/share/hal/fdi/policy/10osvendor/10-storage-policy.fdi. Документация с freedesktop.org не помогла.
В исходниках обнаружено свойство <remove> Например: <remove key="volume.policy.mount_option.fs" type="string"/> type указывать обязательно. Работает только внутри device и match
(In reply to comment #1) > Никто не запрещает запаковать отдельный пакет, изменяющий поведение hal control(8)? 2 eugvv: возможно, самый логичный вариант. :)
control - самый нелогичный вариант. тем более если он будет что-то править в /usr/share/ (файлы не помечены как config, и не будут помечены)
На самом деле нужна схема минимального неизменяемого справочника в /usr/share и рабочие конфиги в /etc, которые могу в том числе и модифицироваться с помощью альтернатив или control
не вижу смысла в control для hal проще сделать конфигуратор а рабочие конфиги в /etc лучше не класть - авторы hal имеют свойство менять его поведение.
Смена поведения штука, конечно, хорошая, но заставлять пользователя править конфиги в /usr/share тоже не лучший выход. А control можно использовать просто как очень удобный механизм переключения альтернатив наподобии select-gcc
А зачем для смены поведения править конфиги в /usr/share ? Достаточно положить перекрывающий конфиг в /etc/hal
Сколько пользователей в процентном отношении будут создавать собственный конфиг, в котором сначала нужно почитав документацию написать правила удаления старых правил, а затем добавить новые правила? Я думаю < 1%... Если же в /usr/share положить только конфиги не предполагающие правки или перекрытия для 90%, а остально положить в /etc/hal, то какой бы вариант настройки не выбрал пользователь - плохой привычки у него не возникнет... А так меня советы из серии vim /usr/share/hal/...fdi напрягают очень сильно - такого не должно быть в нормальном дистрибутиве!
именно. Поэтому я и говорю, что достаточно: или написать модуль к альтератору или запаковать готовые конфиги в пакет. но эти оба пункта явно не ко мне, текущее поведение считаю правильным и обоснованным.
