[Debian] Вопрос об aptitude

> Я могу и в update-alternatives выбрать нужный браузер из выпадающего списка. Тебя не устраивают симлинки как реализация или что?

Меня не устраивает, что никому не нужный костыль тут пытаються выдать за полезную фичу.

Все названия бинарников в типичной unix-системе имеют свое четкое предназначение. Если это sed, значит это sed — он ходит как sed и крякает как sed, и накрякает любому вызвавшему его предсказуемый результат. А если это opera, значит это opera. Изменять пространство имен — это не способ конфигурировать программы. Это не Plan9 с её развитой концепцией пространства имёт. Да, это может печально, но это реальность. Программы конфигурируются через собственные конфиги.

А симлинк some-abstract-browser не ходит и не крякает как браузер — у него нет _поведения_, на которое рассчитывает код, который будет его вызывать. Неужели это так сложно понять?

Если что-то хочет «абстрактный браузер», значит запишем ему в конфиг использовать наш конкретный браузер. Или скрипт, который вызывает браузер с дополнительными ключами. Или вообще не браузер, т.к. нам виднее, что мы хотим получить в итоге.

> Я понятия не имею, как initscripts зависит от mount.

К.О.: Она использует mount, чтобы смонтировать /sys, /dev и /proc.

Когда программа требует хотя бы один компонент из списка - не зависимость? Обоснуй.

Да не требуется твоему апплету ни одна программа из списка. Ему требуется команда, которую он может дернуть, когда пользователь даблкликнет по его иконке (ну или при каких условиях там он её вызывает, хз). А если её оставить пустой или вписать туда несуществующую команду, ничего страшного не произойдёт, просто апплет будет молча показывать число сообщений в почтовом ящике, но браузер открывать не будет.

> Меня не устраивает, что никому не нужный костыль тут пытаються выдать за полезную фичу.

От того, что ты называешь механизм альтернатив никому не нужным костылём - он таким не станет. Можешь уже не повторять.

А симлинк some-abstract-browser не ходит и не крякает как браузер — у него нет _поведения_, на которое рассчитывает код, который будет его вызывать. Неужели это так сложно понять?

У тебя как с памятью? Только что же говорил. Ты скармливаешь браузеру URL, а он начинает не ходить и не крякать, а (внимание) отображать сайт. Это и есть ожидаемое поведение.

Если что-то хочет «абстрактный браузер», значит запишем ему в конфиг использовать наш конкретный браузер. Или скрипт, который вызывает браузер с дополнительными ключами. Или вообще не браузер, т.к. нам виднее, что мы хотим получить в итоге.

А в зависимости чего-то тоже пишем наш конкретный браузер?

> К.О.: Она использует mount, чтобы смонтировать /sys, /dev и /proc.

А апплет использует браузер, чтобы показать тебе почту.

Да не требуется твоему апплету ни одна программа из списка.

Ну представь что он ничего не показывает, а просто молча дёргает браузер

Даже если не будет строгой зависимости от браузера, всё равно при установке программы приятно полглазеть, в чём же можно добраться до веб-интерфейса почты.

> Ты скармливаешь браузеру URL, а он начинает не ходить и не крякать, а (внимание) отображать сайт. Это и есть ожидаемое поведение.

Не будь деревянным. Это ожидаемое поведение браузера для тебя как пользователя. А коду, который вызовет браузер, всё равно, будет он тебе сайт показывать, или из букв URL-а попытается кроссворд построить. Он не завязан на поведение браузера, не ждёт от него никакого фидбека. «Помер Максим, да и хрен с ним.»

> Ну представь что он ничего не показывает, а просто молча дёргает браузер

Так и запишем: у нас есть апплет, который проверяет наличие писем на указанных ящиках и при поступлении новых, передаёт указанной в настройках команде URL для веб-доступа к почтовому ящику. Внимание, вопрос: при чем тут браузер?

> А коду, который вызовет браузер, всё равно, будет он тебе сайт показывать

Не будь деревянным. При любом вызове бинарика с аргументами и при любой передаче текстового потока - никакого фидбека.

> Так и запишем: у нас есть апплет, который проверяет наличие писем на указанных ящиках и при поступлении новых, передаёт указанной в настройках команде URL для веб-доступа к почтовому ящику. Внимание, вопрос: при чем тут браузер?

веб-доступа

браузер

> веб-доступа

браузер

Прошу занести в протокол: melkor217 считает, что с протоколом http умеют работать только браузеры.

Ладно, чтобы там точно был браузер, давай наша программа будет вызывать браузер по кнопке Help, где будет отображаться html-ка с документацией. Rosengarden и solfege так делают, например.

> Прошу занести в протокол: geekless не видит разницу между словами «веб» и «http».

fixed

> При любом вызове бинарика с аргументами и при любой передаче текстового потока - никакого фидбека.

Это очень толсто. Я не верю, что ты настолько тупой, поэтому эта цитата — просто очень толстый и зеленый вброс.

А что, бывает веб не по протоколу http? Сенсация века! :D

А что, ситуация когда мы что-то вызываем/передаём и не получаем фидбека - редкость?

Нет, не бывает.

Дело вот в чём, дружок. Веб - это красивый интернет, в котором ты сейчас сидишь. А http это умный протокол, на котором работает много всяких красивых штуковин, типа Веба. Запомнил?

> Ладно, чтобы там точно был браузер, давай наша программа будет вызывать браузер по кнопке Help, где будет отображаться html-ка с документацией.

Здесь всё еще проще. Пусть вызывает тот браузер, который прописан в DE. А если в DE не прописан браузер, видимо, пользователь либо не хочет, чтобы программы этого DE дергали какой-либо браузер, либо браузера в ситсеме нет. Поэтому пусть показывает message box с сообщением об ошибке. Так что и в этом примере зависимости тоже не нужны.

Вот из-за таких дебильных зависимостей, как в этом примере, и получаются реальные идиотизмы в пакетировании. Представляешь, как при установке какого-нибудь meld или xfe система тебя попросит поставить «какой-нибудь браузер, выберите пожалуйста из списка доступных:», потому что разраб предусмотрел открытие оффсайта по кнопке Help, и «какой-нибудь почтовый клиент, выберите пожалуйста из списка доступных:», потому что разраб предусмотрел еще и возможность написать ему письмо с фидбеком? Ты сразу на ЛОРе в толксах создашь нытик-тред, если тебе система с такими зависимостями попадётся.

> А что, ситуация когда мы что-то вызываем/передаём и не получаем фидбека - редкость?

Когда мы вызываем mount, мы получаем фидбек в виде смонтированного раздела, либо кода ошибки. И, например, initscripts _рассчитывает_ на это вопедение. А от браузера вызывающая сторона ничего не ожидает.

> Дело вот в чём, дружок. Веб - это красивый интернет, в котором ты сейчас сидишь. А http это умный протокол, на котором работает много всяких красивых штуковин, типа Веба. Запомнил?

Тред толстеет прямо на глазах.

А ловко вы нафлудили до 6 страниц =)

Как станете выдыхаться и чуть расправлюсь с работой, попытаюсь открыть теме второе дыхание ссылкой на баг-репорт.

Вообще странные у вас тут разговоры. Никто никогда не будет указывать зависимость от браузера. В проге просто будет вызов вида xdg-open url и пофиг, кто там его открывает. Нужно только предусмотреть возможность того, что дефолтный браузер не выбран и, скажем, выдать сообщение об ошибке. Зависимости на уровне пакетов от браузеровов не нужны.

> Пусть вызывает тот браузер, который прописан в DE.

В каком ещё DE? А может у пользователя ОПЕНБОКС?

Поэтому пусть показывает message box с сообщением об ошибке.

Ну да, зачем пакетный менеджер? Пусть в рантайме всё требует.

Представляешь, как при установке какого-нибудь meld или xfe система тебя попросит поставить «какой-нибудь браузер, выберите пожалуйста из списка доступных:», потому что разраб предусмотрел открытие оффсайта по кнопке Help, и «какой-нибудь почтовый клиент, выберите пожалуйста из списка доступных:», потому что разраб предусмотрел еще и возможность написать ему письмо с фидбеком?

Я бы поглядел на систему без браузера и почтового клиента, лол. Офигевшие зависимости прямо-таки.

> Когда мы вызываем mount, мы получаем фидбек в виде смонтированного раздела, либо кода ошибки.

Когда мы вызываем браузер, мы получаем фидбек в виде возможности очистить счетчик непрочитанных писем, либо кода ошибки.

Просто не нужны, ага. И указывать все просто не будут. Все подумают - а почему бы вместо этого не предусмотреть сообщение об ошибке на случай отсутствия каждой зависимости?

Я уже полдня видоизменяю свой пример, а наш недалёкий товарищ всё придирается к мелочам и подробностям, не вникая в суть. Давайте попробуем иначе. Объясните, почему виртуальные пакеты не нужны. Варианты «не нужно», «высосано из пальца» и «придумано баранами из дебиана» уже предлагались нашим общим другом. Может, у тебя найдётся что-то приличное?

Блин, ну глупо же. ><

Если программа периодичски понимает, что ей нужно показать пользователю веб-страничку - почему бы такой программе не зависеть от браузера? Конечно, не киллер-фича. Но и затраты на реализацию копеечные. Как вообще можно быть против такой ерунды?

Виртуальные пакеты нужны. В Арче они есть. Например, java или phonon-backend. Тут они несут вполне определенный смысл. Но тупые виртуальные пакеты типа «любой терминал» или «любой браузер» не нужны. ИМХО.

> Я бы поглядел на систему без браузера и почтового клиента, лол. Офигевшие зависимости прямо-таки.

У меня не установлен почтовый клиент. Хочешь приехать поглядеть?

> Виртуальные пакеты нужны. В Арче они есть. Например, java или phonon-backend. Тут они несут вполне определенный смысл. Но тупые виртуальные пакеты типа «любой терминал» или «любой браузер» не нужны. ИМХО.

Именно.

> А может у пользователя ОПЕНБОКС?

А создать ~/.local/share/applications/defaults.list не судьба?

Кстати, долго думал, как повторить проблему ТС-а на Арче. Пришло в голову только это. Есть пакет, имеющий виртуальную зависимость java. При его установке выбираем openjdk6. Далее устанавливаем jdk, который уже имеет явную зависимость от jre. Причем jre и openjdk6 по файлам не пересекаются и могли бы существовать параллельно (jre ставится в /opt). Если бы все получилось, то практически очевидно, что при выполнении pacman -Rs jdk, удалился бы и jre, но проверить это не удалось. Оказалось, что пакеты jre и openjdk6 конфликтуют, хотя я так и не понял, в каком месте.

> Если программа периодичски понимает, что ей нужно показать пользователю веб-страничку - почему бы такой программе не зависеть от браузера?

Потому что это _пользовательская_ _настройка_. Ну хватит уже тупить. Хватит.

Польза мелочная конечно. Мало ли там, что-то вызывает опять же справку во внешнем браузере, или процесс запускает во внешнем эмуляторе терминала. Никому бы ничуть не поплохело, если бы этих пакетов не было.

Только наш друг - идеологический противиник этих пакетов. Будет дальше обзываться и строчить полотна текста за идею.

> А создать ~/.local/share/applications/defaults.list не судьба?

Ладно, возьмём другую штуковину, далёкую от DE. Не цепляйся к случайным вещам.

набери-ка `mail` в консольке.

> Потому что это _пользовательская_ _настройка_. Ну хватит уже тупить. Хватит.

Повторюсь. В первую очередь должен быть «общесистемный» дефолт. Который вызывается при отсутствии предпочтений пользователя.

> по файлам не пересекаются и могли бы существовать параллельно

По файлам-то они не пересекаются, но оба ставят в /etc/profile.d/ свой PATH и будут конфликтовать по именам команд — т.к. даже если установить оба, работать будет только тот, который в PATH будет раньше. Хотя, конечно, спорное решение.

набери-ка `mail` в консольке.

vadim@host3:~$ mail
bash: mail: команда не найдена
Status: 127

Можно в двух параллельных терминалах экспортировать переменную, с какой джавой хочешь работать, и пользоваться обеими сразу. Причем тем, кто на джаве программирует, это было бы весьма полезно.

Ой, кажется КОНФЛИКТ. Ну что же, осталось вообразить две программы, зависящих от разных реализаций джавы.

Странный ваш арч какой-то. В дебианах и редхатах по умолчанию есть локальная почта, куда cron и компания шлют всякие интересные штуки.

> Повторюсь. В первую очередь должен быть «общесистемный» дефолт. Который вызывается при отсутствии предпочтений пользователя.

1. В системе A не установлен браузер, но на ней крутится несколько приложений, включая твой апплет.
2. В системе B установлен браузер и куча других полезных вещей.
3. Пользователь пользуется приложениями с обеих систем на одном дисплее.
4. Пользователь в качестве «браузера» для апплета на машине A вписал скрипт, который через иксы отправляет команду открытия в окно firefox, который работает на машине B.

Внимание, вопрос: какой должен быть «общесистемный» дефолт на машине A, и как на неё поставить этот апплет, не ставя браузер?

Если скажешь, что пример не реален, то отвечаю, что вся эта история с апплетом не реальна с самого начала.

> Можно в двух параллельных терминалах экспортировать переменную, с какой джавой хочешь работать, и пользоваться обеими сразу. Причем тем, кто на джаве программирует, это было бы весьма полезно.

Вот поэтому и спорное. Ну в крайнем случае можно просто выкинуть описание конфликта из определения пакета, это ж система-конструктор всё-таки. :)

> Ой, кажется КОНФЛИКТ. Ну что же, осталось вообразить две программы, зависящих от разных реализаций джавы.

Вообрази.

Как придумаешь, следом еще вообрази обязательно, как на дебиане этот конфликт легко и просто разруливается.

> Ой, кажется КОНФЛИКТ. Ну что же, осталось вообразить две программы, зависящих от разных реализаций джавы.

Поправить список конфликтующих пакетов не сложно. Но да, тут мейнтейнеры Арча не очень красиво поступили.

> Странный ваш арч какой-то. В дебианах и редхатах по умолчанию есть локальная почта, куда cron и компания шлют всякие интересные штуки.

Интересные штуки лучше слать в логи. А уж куда логи надо будет отсылать — админ сам разберётся.

> Ладно, возьмём другую штуковину, далёкую от DE. Не цепляйся к случайным вещам.

На мой взгляд, в зависимости конкретного пакета нужно пихать только всякие so-шки, с которыми этот пакет собирался и без которых он тупо не запустится, или приложения, которые явно выполняются внутри текущего пакета (как, например, в гуишном фронтенде). Все остальное баловство.

Встречал в Убунте ситуацию, когда при удалении firefox сразу устанавливался другой браузер. При удалении этого нового браузер, ставился назад firefox. Вот это, блин, точно не правильно.

> Внимание, вопрос: какой должен быть «общесистемный» дефолт на машине A, и как на неё поставить этот апплет, не ставя браузер?

Вот из-за таких любителей недокументированных возможностей - зависимость от браузера нестрогая. Намекает, как использовать по назначению, но даёт простор для извращений.

Если скажешь, что пример не реален, то отвечаю, что вся эта история с апплетом не реальна с самого начала.

http://packages.debian.org/sid/gmail-notify прости, дружок :(

> Вот из-за таких любителей недокументированных возможностей - зависимость от браузера нестрогая.

Нестрогая зависимость == несуществующая зависимость. Расслабься уже.

http://packages.debian.org/sid/gmail-notify

Что и требовалось доказать. recommends означает не функциональную зависимость, а рекомендацию пользователю использовать совместно с. Чисто-справочная информация.

прости, дружок :(

Ну и что ты этим хотел сказать? Что я не знал про нотификаторы для трея? Крепкая тебе досталась чудо-трава.

> На мой взгляд, в зависимости конкретного пакета нужно пихать только всякие so-шки, с которыми этот пакет собирался и без которых он тупо не запустится, или приложения, которые явно выполняются внутри текущего пакета (как, например, в гуишном фронтенде). Все остальное баловство.

Ну, всякое баловство типа браузеров как раз почти не встретишь в зависимостях. А в рекомендациях - понятное дело.

Встречал в Убунте ситуацию, когда при удалении firefox сразу устанавливался другой браузер. При удалении этого нового браузер, ставился назад firefox. Вот это, блин, точно не правильно.

Ну это убунта, там гламурный менеджер приложения думает за тебя. Aptitude тоже почти наверняка предложит заменить Fx другим браузером (если от браузера что-то всё же зависит), но следующим же вариантом разрешения конфликта будет снести всё к чертям.

> geekless

Не на мой коммент ответил.