Комментарии 22
При этом из системы было удалено 7278 пакетов (13% от общего объема предыдущей версии). Все они не подлежат обновлению и получили пометку «устаревшие».
Как я люблю когда обратную совместимость ломают. Там что, перешли на 128 разрядов, что пакеты несовместимы стали? Или код заржавел?
Как я люблю когда обратную совместимость ломают.Кто вам сказал что тут что-то сломали? Они ж не удаляют их из системы, а исключают из дистрибутива. Если бы «совместимость сломали» — пришлось бы из системы удалять.
Или код заржавел?В большинстве случаев «разработчик заржавел»: баги есть, реакции нет. Ну и что должны люди из Debian'а делать? Становиться разработчиками для всех десятков тысяч пакетов?
Хотите, чтобы ваш любимый пакет вернулся — берите на себя техподдержку, пакет оживят. Это несложно.
В большинстве случаев «разработчик заржавел»...
Не знаю про "большинство", но очень часто "заржавел(и)" как раз maintainer(ы).
Т.е. разрабы нередко уже даленько-даленько, а в пакетах воз и ныне там…
И особливо оно касается как раз дебианов, к сожалению, по целому ряду причин, см. например...
берите на себя техподдержку, пакет оживят. Это несложно.
Ну, ну… флаг, как говорится, барабан… все дела...
Ну, ну…Ну если вам это не нужно — то почему это кому-то ещё должно быть нужно?флаг, как говорится, барабан… все дела...
А с тем, что сама идея: а давайте весь мир стащим к себе в норку — устарела… я как раз согласен. Она была, наверное, хороша четверть века назад, когда скачать гиг было подвигом, а с пакетами в Debian или RedHat круто: купил комплект из 2-3-5-10 CD — и у тебя прям сразу весь софт на полке… но и CD уже все пользоваться перестали и трафик перестали делить на «дневной» и «ночной»… а вот — всё ныне там.
Ну если вам это не нужно — то почему это кому-то ещё должно быть нужно?
Я так-то в большей степени разраб, и на активно что-нибудь еще мэйнтэйнить просто времени нет совсем (ибо будет вероятно в ущерб остальному). Так что тут — вы мимо...
И нет, то было скорее ответом на "Это не сложно"… ибо я как раз таки согласен со Штапельбергом.
Возможно "сложно" здесь не совсем верно — есть такое слово "муторно" — так вот оно — то самое скорее. (А еще утомительно, раздражает и многое многое другое).
Тот же apt иногда выбешивает не по-детски… Вот для примера из недавнего:
Намедни нужен был мне в трависе (CI) на xenial tcl8.6 (>= 8.6.9, а родной там 8.6.5)… ну т.е. ставим из репа для старшей версии… и вот откуда-то там взялась зависимость к locales 2.29 (через libc и ко), который тупо ставится скриптом генерируя каждый locale на месте, а затем еще тащит обновления для всех postgresql (на минутку для каждого снапшота, тестируемого компилятора, и т.д.) и выключить эти обновление не представляется возможным… т.е. совсем выпилить те пакеты можно (например apt-get install -t disco -y tcl8.6 tcl8.6-dev locales- 'postgresql*-'), а вот тупо обновить всё нужное, проигнорировав обновление locales и т.д. — выкуси (хоть пиннинг, хоть apt-mark hold, и т.д.)…
Опять же есть такая опция "--no-upgrade", вот кто-нибудь может внятно объяснить что если написано:
apt-get install --no-install-recommends --no-upgrade -t disco -y tcl8.6 tcl8.6-devт.е. явно указано что хочу установить 2 пакета из disco (и не апгрэйтить остальное), какого оно говорит "Skipping tcl8.6, it is already installed and upgrade is not set."?
Т.е. нужна видимо новая (двухсотая уже) опция типа --no-upgrade-but-install.
Вот и получается, что или ждать пока CI полчаса всё то установит, проверит, и т.д. (когда сама компиляция и тесты собственно менее 20-ти секунд занимают) или "велосипедить" что-то типа:
$ for fn in $(apt-get --print-uris --yes install tcl8.6 tcl8.6-dev | grep -P ' (lib)?(tcl|c)' | grep -oP "(?<=^')\S+(?=')")
do
n=$(basename -- "$fn")
echo "$n ..."; n="/tmp/pck-$n"; rm -f "$n";
wget -q -O "$n" "$fn";
sudo dpkg -i --force-all "$n";
rm -f "$n";
doneт.е. ставить нужные пакеты dpkg ручками.
И это всё вообще-то элементарщина, а maintainer(ы) такого порассказывают иногда...
т.е. явно указано что хочу установить 2 пакета из disco (и не апгрэйтить остальное), какого оно говорит «Skipping tcl8.6, it is already installed and upgrade is not set.»?Нет, вы не сказали «установить 2 пакета из disco». Вы сказали «установить два пакета, если их нету, а взять их можно и из disco тоже».
Т.е. нужна видимо новая (двухсотая уже) опция типа --no-upgrade-but-install.Не нужно вам ничего. Если хотите поставить два пакета — возьмите dpkg и поставьте. APT — это тулза, нужная для управления зависимостями, а просто пакеты ставятся dpkg. Как, собственно, вы и написали…
И это всё вообще-то элементарщина, а maintainer(ы) такого порассказывают иногда...А у них просто нет желания поддерживать все возможные комбинации всех возможных пакетов. Ибо комбинаторный взрыв и ничем хорошим оно не кончается. Потому что вся идеология пакетов не сочетается с тем, как современный софт разрабатывается. Если бы программы были готовы на лету принимать разные версии разных компонент — то это всё могло бы работать.
Но они, по большей части, стремятся всё, что возможно выяснить о системе во время сборки и зашить в бинарник. Те, которые не трубуют жёстко какую-то определённую версию. Вот скажем вас же пример: с какого перепугу вам вообще потребовался TCL 8.6.9 и почему TCL 8.6.5 вас не устраивает?
С таким подходом идея пакетов вообще становится нереализуемой: нужно делать как в Android или ChromeOS: зашивать всё в систему, а всё чего в системе нету — приложения должны с собой носить.
Но признать это Linux-community не может… потому и имеем то, что имеем.
Если хотите поставить два пакета — возьмите dpkg и поставьте.
Ага — отвелосипедить то есть… создать список того что надо (в нужной последовательности, скачать ручками, и т.д. и т.п.
APT — это тулза, нужная для управления зависимостями.
Вообще-то нет (ну, или не только)… оно себя заявляет как пакетный манагер… например оно еще и скачать может, и в правильной последовательности накатить то что надо и т.д.
С какого перепугу вам вообще потребовался TCL 8.6.9 и почему TCL 8.6.5 вас не устраивает?
Ну я же писал о CI (т.е. надо оттестировать что-то)… С того перепугу, что мы (ну как мы, вообще-то Натан и Дон) в версиях 8.6.8 и особливо 8.6.9 кое-чего "поломали" (в частности NRE trampoline в связке с резолверами ассемблей), и если тестировать какое-либо расширение для Тикля, использующее внутренние API (а бинарная совместимость гарантируется только для public-API), то нужно это делать для всех версий, для которых их потом выльют.
Мэйнтейнеры тоже знаете ли не всё могут знать/проверять...
С таким подходом идея пакетов вообще становится нереализуемой
Т.е. вы разрабу Tcl сейчас пытаетесь рассказать про зависимости оного… Ну, ну.
Если что, как и с чем его и его модули собирать и откуда чего брать я прекрасно осведомлен…
А в виртуальном снэпшоте CI что-то поломать из зависимостей… да мне как-то до одного места оно.
Просто для скорости иногда хочется (или тупо нужно) и "тяп-ляп" и поломать чего можно, главное что бы быстро и не муторно.
Вы вообще видели когда-нибудь как оно тестируется… И сколько иногда надо ждать, чтобы узнать что с включенной опцией O для платформы X, в 32-битном варианте что-то безвозвратно "поломалось".
А если нужно дальше код писать на той базе (чтобы не переписывать по десять раз потом), и/или тебя еще трое разрабов ждут…
И не забывайте, что это нередко вовсе неосновная работа (и нужно еще и той заниматься за которую платят), да еще и не единственный проект как правило...
Так что ваше "Это несложно", извините, но как минимум режет слух (повторюсь — особливо для дебианов)… и очень многие мэйнтейнеры с вами тут не согласятся.
Ага — отвелосипедить то есть… создать список того что надо (в нужной последовательности, скачать ручками, и т.д. и т.п.А как иначе? Вы либо верите в зависимости, либо нет. Какие ещё есть варианты?
Вообще-то нет (ну, или не только)… оно себя заявляет как пакетный манагер… например оно еще и скачать может, и в правильной последовательности накатить то что надо и т.д.Это всё — надстройки над основной функциональностью.
Мэйнтейнеры тоже знаете ли не всё могут знать/проверять...И вы сами рассказали — почему. Потому что разработчики пользуются внутренними интерфейсами и «забивают на совместимость». Так какие претензии к мейнтенерам?
Так что ваше «Это несложно», извините, но как минимум режет слух«Несложно» — это говорилось про оживление пакетов. Если их разработчики перестанут «заниматься фигнёй». Перестанут использовать внутренние API. Перестанут связывать «намертво» версии разных компонент. И прочее.
Ну а если разрабам всё равно, то единственный работающий путь — это как у Android или ChromeOS: никаких отдельных пакетов и никакого APT. Раз в полгода (у ChromeOS — шесть недель) выкатывается новая версия. И какие пакеты вы там получили — такие и используйте.
Потому что сейчас у вас проблемы ровно оттого, что мистические «другие разработчики» делают то же, что и вы. А почему вам можно, а им нельзя?
Т.е. вы разрабу Tcl сейчас пытаетесь рассказать про зависимости оного… Ну, ну.Нет, я рассказываю человеку, плюющему в колодец, что вода в нём плохая не потому что колодец не чистят, а потому, что другие делают то же самое, что и вы.
А как иначе? Вы либо верите в зависимости, либо нет. Какие ещё есть варианты?
Т.е. вы из тех которые никогда никогда rm -fr ... не используют? (потому что опасно!) Тогда я сливаюсь с ветки… Нам правда нечего больше обсуждать.
И вы сами рассказали — почему. Потому что разработчики пользуются внутренними интерфейсами и «забивают на совместимость».
WTF? Конечно разработчики пользуются внутренними интерфейсами. А для чего они по вашему есть вообще?
И где вы увидели про «забивают на совместимость»?
Потому что сейчас у вас проблемы ровно оттого, что мистические «другие разработчики» делают то же, что и вы. А почему вам можно, а им нельзя?
У меня/нас нет проблем. От слова совсем. Вы во первых повидимому просто не в теме как разработка больших проектов ведется в принципе.
А во вторых тут конкретно вообще мимо — ибо Tcl (по сравнению с многими другими) это проъект с великолепной обратной совместимостью.
Нет, я рассказываю человеку, плюющему в колодец, что вода в нём плохая не потому что колодец не чистят, а потому, что другие делают то же самое, что и вы.
Чаво?
Т.е. если вы к примеру увидели что кто-то, где-то использует шуруповерт в качестве молотка (один раз, потому что просто под рукой и удобно тут) — вы на этом основании делаете вывод что во первых он всегда и везде так делает, а во вторых "что и другие делают то же самое, что и он".
Серьезно? У вас правда с логикой всё нормально?
Вангую, что опционально, но всё же не понимаю — зачем?
P.S. Только не надо прям щаз бенчмарки пускать. Понятно, что ещё потребуется какое-то время для того, чтобы перейти от эмуляции к нативному решению. А сейчас вы этой поддержкой всё только замедлите: вначале ядро будет делать всё необходимое для поддержки case-insensitivity, а потом — Samba… второй раз.
(В первые несколько дней скорости были намного выше.)
поддержку case-insensitive имен для файловой системы ext4
О боже, зачем это?!?
Не, пусть в винду linux добавляют — мне не жалко, но зачем
Состоялись релизы Debian 10 Buster и Linux 5.2