История изменений

в чем ересь в желании на этапе описания пакета в точности знать все файлы, которые в него включены? Это желание такого же толка, как на этапе компиляции программы знать типы и пути выполнения (эта та причина, по которой динамические языки не нужны :))

кстати, можно реализовать какой-нибудь API, который мог бы модифицировать БД пакетов. Например, создаешь ты своим приложением/модулем файл, и этот файл тут же добавляется в базу данных пакетника, как «созданный пакетом после установки». Там же можно сразу выбирать «предназначения» файлов, что-то типа тэгов, чтобы делать над ними групповые опреации типа «удалить все файлы с тэгом text-file, созданные любой программой из пакета emacs».

Или даже жестче, пропатчить такой следилкой код файловых вызовов: всё что создано программой даже без использования специального апи будет в обязаловку удалено вместе с пакетом этой программы. Исключая, может быть, /home или другое специально сконфигурированное для «пользовательских данных» место.

И, конечно же, добавить это в systemd.

в чем ересь в желании на этапе описания пакета в точности знать все файлы, которые в него включены? Это желание такого же толка, как на этапе компиляции программы знать типы и пути выполнения (эта та причина, по которой динамические языки не нужны :))

кстати, можно реализовать какой-нибудь API, который мог бы модифицировать БД пакетов. Например, создаешь ты своим приложением/модулем файл, и этот файл тут же добавляется в базу данных пакетника, как «созданный пакетом после установки». Там же можно сразу выбирать «предназначения» файлов, что-то типа тэгов, чтобы делать над ними групповые опреации типа «удалить все файлы с тэгом text-file, созданные любой программой из пакета emacs».

Или даже жестче, пропатчить такой следилкой код файловых вызовов: всё что создано программой даже без использования специального апи будет в обязаловку удалено вместе с пакетом этой программы. Исключая, может быть, /home или другое специально сконфигурированное для «пользовательских данных» место.