керування версіями для / тощо під * BSD

Які рішення "під ключ" існують для того, щоб їх можна було /etcконтролювати версією, під різними рішеннями? "Під ключ" не обов'язково означає частину базової установки, але було б непогано такі функції:

• підключається до команд VCS для управління метаданими (право власності, дозволи);
• інтеграція з менеджером пакунків (запускати автоматично до та після встановлення, обробляти оновлення інтелектуально);
• трактувати версії файлів вище за потоком як гілку;
• попередньо заповнений список ігнорування;
• підтримка декількох VCS (особливо розподілених).

Я використовую etckeeper під Debian та похідними. Він має всі перераховані вище функції, за винятком того, що він не відслідковує версії за потоком. Я хотів би дізнатися про альтернативи, зокрема на * BSD.

У Gentoo інструмент для управління пакетом змін / etc (званий dispatch-conf) підтримує rcs для відстеження змін, але це не дуже потужно.

Я схильний до версії my / etc via git, тим більше, що, використовуючи різні гілки, я можу зберегти свій / etc якомога подібніший за різними дистрибутивами, зберігаючи якомога більше речей в одному місці, наскільки це можливо (для деяких областей, які явно не вдається, конфігурація apache наприклад, дійсно різна в різних дистрибутивах). Це працює так:

У мене є masterрепо з файлами конфігурації за замовчуванням. Тепер я контактую з новим дистрибутивом, тому створюю нову гілку на основі своєї masterгілки на основі імені дистрибутива (у цьому прикладі debian). Debian зберігає деякий конфігураційний файл у місці, відмінному від мого, masterтому я це роблю git mv file new_loc. І все добре. Я повертаюсь назад masterі змінюю цей файл, тому що я додав певну директиву конфігурації, коли я зливаюсь masterу свою debianгілку, переміщений файл змінюється, тому я в основному можу просто змінити більшість речей у своїй masterгілці, і просто доведеться об'єднати зміни в моєму "розподілі" гілки (зазвичай вони, як правило, більше суміші гілок розподілу та призначення, сервер debian очевидно має деякі відмінності від робочої станції debian, але функції все ще працюють).

Таким чином, я маю "загальну конфігурацію" в master(і сказати це в об'єктно-орієнтованому програмуванні термінах) успадковую їх у мої гілки (які також можуть успадковувати один від одного).

Окрім цього, gitмеханізми «вишневого вибору» (у цьому випадку зміни в / etc /) були мені дуже корисними в моменти, коли мені потрібні були лише частини певної конфігурації.

Тепер до деяких ваших ідей:

• Якби мені була потрібна додаткова інтеграція менеджера пакунків, я, мабуть, використовував би для цього сценарії обгортки (на даний момент цього не роблю).
• трактувати версії за течією, як гілку, буде добре працювати git, це просто інша гілка, яку ви іноді об'єднуєте (частково) вmaster
• Список ігнорів у git - це файл .gitignore у вашій репо-репортажі, щоб він був охоплений.

Я використовував fossilдля цього з деяким успіхом. Перегляньте мій пост про Fossil для отримання додаткової інформації. Я також використовував інструмент під назвою, etcupdateякий скоріше рухається між оновленнями, ніж відстеження змін. Я вважаю, що це покликане було стати інструментом супутника freebsd-updateв один момент. Я зараз не впевнений у його статусі, але він працює у моїх RELEASE-8.*системах.

http://lists.freebsd.org/pipermail/freebsd-current/2010-June/017927.html http://people.freebsd.org/~jhb/etcupdate/

Є інструмент під назвою etckeeper Я не знаю, наскільки це добре.

etckeeper - це набір інструментів, які дозволяють / тощо зберігатись у сховищі git, mercurial, darcs або bzr. Він підключається до apt (та інших менеджерів пакетів, включаючи yum та pacman-g2), щоб автоматично здійснювати зміни, внесені в / etc під час оновлення пакету. Він відслідковує метадані файлів, які системи керування переглядом зазвичай не підтримують, але це важливо для / і т.д., наприклад, дозволи / etc / shadow. Він досить модульний і настроюється, а також простий у використанні, якщо ви розумієте основи роботи з контролем редагування.

Я також не знаю, чи можна змусити працювати над * BSD, я підозрюю, що це могло, але це не буде підтримуватися з портами поза коробкою.