Прошу убрать из /usr/lib/rpm/0common-files.req.list строку: /etc/xinetd.d xinetd
(In reply to comment #0) > Прошу убрать из /usr/lib/rpm/0common-files.req.list строку: > /etc/xinetd.d xinetd Я хочу, чтобы каталог /etc/xinetd.d был запакован только в пакете xinetd.
2led: А какому другому пакету может потребоваться владеть каталогом /etc/xinetd.d?
(В ответ на комментарий №1) > Я хочу, чтобы каталог /etc/xinetd.d был запакован только в пакете xinetd. Понятно. Значит демоны, которые могут работать и через xinetd, и standalone у нас принципиально запрещены? Или ставить зависмость на xinetd придётся в любом случае, даже если предполагаю установить использовать демон только в standalone режиме?
(In reply to comment #3) > (В ответ на комментарий №1) > > Я хочу, чтобы каталог /etc/xinetd.d был запакован только в пакете xinetd. > > Понятно. Значит демоны, которые могут работать и через xinetd, и standalone у > нас принципиально запрещены? С чего бы вдруг? > Или ставить зависмость на xinetd придётся в любом > случае, даже если предполагаю установить использовать демон только в standalone > режиме? Зависимость поставится сама. А чем она мешает?
(В ответ на комментарий №4) > Зависимость поставится сама. А чем она мешает? Тем, что пакет будет вытягивать по зависмостям xinetd (при том, что в системе он не нужен)
(В ответ на комментарий №4) > Зависимость поставится сама. А чем она мешает? Например, на тонком клиенте может не быть достаточно места. 2led: как вариант - mydaemon и mydaemon-xinetd, второй зависит от mydaemon и xinetd.
(В ответ на комментарий №6) > 2led: как вариант - mydaemon и mydaemon-xinetd, второй зависит от mydaemon и > xinetd. Не вариант. потому что после обновления пакета (который раньше был xinetd-only) пользователь "потеряет" его из системы.
Тогда наоборот: mydaemon и mydaemon-standalone.
(В ответ на комментарий №8) > Тогда наоборот: mydaemon и mydaemon-standalone. И зависимость mydaemon -> mydaemon-standalone? Есть какие-то другие причины, кроме указанных в "comment #1", чтобы городить всё это, вынося в отдельный пакет только невесомый, никому не мешающий скрипт размером < 0.5К?
Если не выносить отдельно - получится пакет с неполными зависимостями, требующий доустановки xinetd для работы с xinetd. В этом случае, скажем, создание какого-нибудь VE-шаблона потребует дополнительных плясок с набором пакетов, чтобы получить работающий через xinetd сервис. Возможно, для данного (какого, кстати?) демона это неважно, но это создаст прецедент для других.
(В ответ на комментарий №10) > Если не выносить отдельно - получится пакет с неполными зависимостями, > требующий доустановки xinetd для работы с xinetd. > > В этом случае, скажем, создание какого-нибудь VE-шаблона потребует > дополнительных плясок с набором пакетов, чтобы получить работающий через xinetd > сервис. Если этот сервис работает только через xinetd, то почему в нём не проставлено Requires: xinetd ? Это явная бага упаковки такого пакета. > > Возможно, для данного (какого, кстати?) В данный момент - tftpd > демона это неважно, но это создаст > прецедент для других. да, это создаст возможность для других пакетов иметь возможность работать и через xinetd, и standalone
(В ответ на комментарий №11) > Если этот сервис работает только через xinetd, то почему в нём не проставлено > Requires: xinetd? Это явная бага упаковки такого пакета. Нет, как раз наоборот: если сервис работает и так, и так. Т.е. для VE-шки с tftpd-через-xinetd придётся указывать оба пакета: и tftpd, и xinetd, что есть нехорошо: зависимость потеряна. > > демона это неважно, но это создаст прецедент для других. > да, это создаст возможность для других пакетов иметь возможность работать и > через xinetd, и standalone Это сомнительный путь: субпакет с поддержкой xinetd тоже даёт возможность работать и через xinetd, и standalone, при этом зависимости остаются корректными, и, что более важно, явными: два пакета в выводе apt-cache search, с различающимся описанием гораздо лучше самодокументированы, чем один, с неявной слабой зависимостью на xinted.
(В ответ на комментарий №12) > (В ответ на комментарий №11) > > > Если этот сервис работает только через xinetd, то почему в нём не проставлено > > Requires: xinetd? Это явная бага упаковки такого пакета. > > Нет, как раз наоборот: если сервис работает и так, и так. > > Т.е. для VE-шки с tftpd-через-xinetd придётся указывать оба пакета: и tftpd, и > xinetd, что есть нехорошо: зависимость потеряна. Какая зависимость? Для tftpd не требуется xinetd - он и без xinetd отлично работает. Если же кому-то требуется, чтобы tftpd работал именно через xinetd, он поставит (или доавит в список) xinetd. Что здесь нелогично? > Это сомнительный путь: субпакет с поддержкой xinetd тоже даёт возможность > работать и через xinetd, и standalone, при этом зависимости остаются > корректными, Они так корректны. tftpd не требует для своей корректной работы обязательного наличия xinetd. > и, что более важно, явными: два пакета в выводе apt-cache search, > с различающимся описанием гораздо лучше самодокументированы, чем один, с > неявной слабой зависимостью на xinted. У меня прямо противоположное мнение на этот счёт:)
С одной стороны - xinetd-скрипт слишком мелок, чтобы его отпиливать в подпакет. С другой - точка зрения Димы, что все сервисы, работающие через xinetd (даже если это только один из вариантов их работы), должны зависеть от xinetd, тоже понятна. Вероятно, субпакет тут является оптимальным компромиссом (жаль, что нельзя сделать-таки tftpd и tftpd-xinetd, было бы нагляднее).
Может основной мейнтейнер tftp выскажет своё мнение? Мне он любезно разрешил положить в Sisyphus пододную сборку, но городить костыли вокруг tftp-server в виде полукилобайтовых пакетов врядли одобрит:) Да и самому мне это неинтересно, из-за того, что достаточных причин для этого мне так никто и не указал:) Вижу только, что компромиса не получается (наверное, у меня слишком извращенные запросы) и теперь ещё и rpm с tfpp-server'ом в Sisyphus для моих задач абсолютно не подходят - значит будем пользоваться своими:)
(В ответ на комментарий №14) > С другой - точка зрения Димы, что все сервисы, работающие через xinetd (даже > если это только один из вариантов их работы), должны зависеть от xinetd, тоже понятна. Мне кажется вы неправильно поняли его точку зрения. ИМХО она не в том, что "все сервисы, работающие через xinetd должны зависеть от xinetd", потому что это очень легко решается без прибивания гвоздями /etc/xinet.d в 0common-files.req.list:)
Мантейнер tftp не понимает этой глупой войны с 0common-files.req.list. Также мантейнер не понимает, почему так сложно напилить пакет потоньше. Мне лично не жалко дополнительных 10 килобайт на дополнительный пакет в Сизифе, лишь бы на системах, где каждый бит дискового пространства на счету, можно было сэкономить 300 килобайт на xinetd. Поэтому, надо делать так: Делается пакет tftp-server-common, содержащий то же, что сейчас содержит tftp-server, но без скрипта для xinetd В пакете tftp-server остается скрипт для xinetd и добавляется зависимость на tftp-server-common Делается пакет tftp-server-standalone, содержащий init-скрипт, с зависимостью на tftp-server-common. Что я упустил?
А, еще можно пакет tftp-server переименовать в tftp-server-xinetd через provides/obsoletes.
(В ответ на комментарий №17) > Мантейнер tftp не понимает этой глупой войны с 0common-files.req.list. Нет никакой "войны". Просто натыкаюсь на это почти каждый день:) > Также > мантейнер не понимает, почему так сложно напилить пакет потоньше. Ок, если можно - "напилим":)
(В ответ на комментарий №18) > А, еще можно пакет tftp-server переименовать в tftp-server-xinetd через > provides/obsoletes. И первый, и второй предложенный вами вариант я рассматривал. Так как вы не против, то так и сделаю, остановившись на втором варианте. Правда вызывает сомнение: нужен ли provides, не достаточно ли одного obsoletes?
Не знаю, достаточно ли одного obsoletes. По идее provides нужен для того, чтобы даже после удаления пакета tftp-server из репозитария можно было делать apt-get install tftp-server. А obsoletes нужен для того, чтобы уже присутствующий в системе пакет tftp-server был заменен на tftp-server-xinetd при выполнении dist-upgrade. Я лично всегда делаю и provides, и obsoletes. Возможно, это просто перестраховка.
так вопрос решился другим способом, наверное, стОит считать, что NOTABUG
