Ads
Comments 20
+1
Спасибо, обновился, но обидно что cherrytree из коробки не работает, придется собирать
+2
При этом из системы было удалено 7278 пакетов (13% от общего объема предыдущей версии). Все они не подлежат обновлению и получили пометку «устаревшие».

Как я люблю когда обратную совместимость ломают. Там что, перешли на 128 разрядов, что пакеты несовместимы стали? Или код заржавел?
+7
Как я люблю когда обратную совместимость ломают.
Кто вам сказал что тут что-то сломали? Они ж не удаляют их из системы, а исключают из дистрибутива. Если бы «совместимость сломали» — пришлось бы из системы удалять.

Или код заржавел?
В большинстве случаев «разработчик заржавел»: баги есть, реакции нет. Ну и что должны люди из Debian'а делать? Становиться разработчиками для всех десятков тысяч пакетов?

Хотите, чтобы ваш любимый пакет вернулся — берите на себя техподдержку, пакет оживят. Это несложно.
0
В большинстве случаев «разработчик заржавел»...

Не знаю про "большинство", но очень часто "заржавел(и)" как раз maintainer(ы).
Т.е. разрабы нередко уже даленько-даленько, а в пакетах воз и ныне там…
И особливо оно касается как раз дебианов, к сожалению, по целому ряду причин, см. например...


берите на себя техподдержку, пакет оживят. Это несложно.

Ну, ну… флаг, как говорится, барабан… все дела...

0
Ну, ну… флаг, как говорится, барабан… все дела...
Ну если вам это не нужно — то почему это кому-то ещё должно быть нужно?

А с тем, что сама идея: а давайте весь мир стащим к себе в норку — устарела… я как раз согласен. Она была, наверное, хороша четверть века назад, когда скачать гиг было подвигом, а с пакетами в Debian или RedHat круто: купил комплект из 2-3-5-10 CD — и у тебя прям сразу весь софт на полке… но и CD уже все пользоваться перестали и трафик перестали делить на «дневной» и «ночной»… а вот — всё ныне там.
+1
Ну если вам это не нужно — то почему это кому-то ещё должно быть нужно?

Я так-то в большей степени разраб, и на активно что-нибудь еще мэйнтэйнить просто времени нет совсем (ибо будет вероятно в ущерб остальному). Так что тут — вы мимо...


И нет, то было скорее ответом на "Это не сложно"… ибо я как раз таки согласен со Штапельбергом.
Возможно "сложно" здесь не совсем верно — есть такое слово "муторно" — так вот оно — то самое скорее. (А еще утомительно, раздражает и многое многое другое).


Тот же 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(ы) такого порассказывают иногда...

0
т.е. явно указано что хочу установить 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 не может… потому и имеем то, что имеем.
0
Если хотите поставить два пакета — возьмите 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-битном варианте что-то безвозвратно "поломалось".
А если нужно дальше код писать на той базе (чтобы не переписывать по десять раз потом), и/или тебя еще трое разрабов ждут…
И не забывайте, что это нередко вовсе неосновная работа (и нужно еще и той заниматься за которую платят), да еще и не единственный проект как правило...


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

0
Ага — отвелосипедить то есть… создать список того что надо (в нужной последовательности, скачать ручками, и т.д. и т.п.
А как иначе? Вы либо верите в зависимости, либо нет. Какие ещё есть варианты?

Вообще-то нет (ну, или не только)… оно себя заявляет как пакетный манагер… например оно еще и скачать может, и в правильной последовательности накатить то что надо и т.д.
Это всё — надстройки над основной функциональностью.

Мэйнтейнеры тоже знаете ли не всё могут знать/проверять...
И вы сами рассказали — почему. Потому что разработчики пользуются внутренними интерфейсами и «забивают на совместимость». Так какие претензии к мейнтенерам?

Так что ваше «Это несложно», извините, но как минимум режет слух
«Несложно» — это говорилось про оживление пакетов. Если их разработчики перестанут «заниматься фигнёй». Перестанут использовать внутренние API. Перестанут связывать «намертво» версии разных компонент. И прочее.

Ну а если разрабам всё равно, то единственный работающий путь — это как у Android или ChromeOS: никаких отдельных пакетов и никакого APT. Раз в полгода (у ChromeOS — шесть недель) выкатывается новая версия. И какие пакеты вы там получили — такие и используйте.

Потому что сейчас у вас проблемы ровно оттого, что мистические «другие разработчики» делают то же, что и вы. А почему вам можно, а им нельзя?

Т.е. вы разрабу Tcl сейчас пытаетесь рассказать про зависимости оного… Ну, ну.
Нет, я рассказываю человеку, плюющему в колодец, что вода в нём плохая не потому что колодец не чистят, а потому, что другие делают то же самое, что и вы.
0
А как иначе? Вы либо верите в зависимости, либо нет. Какие ещё есть варианты?

Т.е. вы из тех которые никогда никогда rm -fr ... не используют? (потому что опасно!) Тогда я сливаюсь с ветки… Нам правда нечего больше обсуждать.


И вы сами рассказали — почему. Потому что разработчики пользуются внутренними интерфейсами и «забивают на совместимость».

WTF? Конечно разработчики пользуются внутренними интерфейсами. А для чего они по вашему есть вообще?
И где вы увидели про «забивают на совместимость»?


Потому что сейчас у вас проблемы ровно оттого, что мистические «другие разработчики» делают то же, что и вы. А почему вам можно, а им нельзя?

У меня/нас нет проблем. От слова совсем. Вы во первых повидимому просто не в теме как разработка больших проектов ведется в принципе.
А во вторых тут конкретно вообще мимо — ибо Tcl (по сравнению с многими другими) это проъект с великолепной обратной совместимостью.


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

Чаво?
Т.е. если вы к примеру увидели что кто-то, где-то использует шуруповерт в качестве молотка (один раз, потому что просто под рукой и удобно тут) — вы на этом основании делаете вывод что во первых он всегда и везде так делает, а во вторых "что и другие делают то же самое, что и он".


Серьезно? У вас правда с логикой всё нормально?

0
Все свое ношу с собой реализовала Intel в ClearLinux OS, там либо бандлы со всеми зависимостями (независимо), либо plainpackage или как там они их назвали. Кроме того инкрементальные апдейты только измененный файлов внутри бандла или пакета, а-ля git.
+3
case-insensitive filesystem это же плохо нам сделали, теперь будет file и FiLe одно и то же?
+2
Оно-же по желанию включается. По-умолчанию выключено.
+1

Если я правильно помню, флаг case-insensitive вообще ставится для отдельных каталогов (впрочем, никто не мешает поставить на корневой)

+2
А это реально может создать какие-то проблемы? То есть линукс конечно позволяет такое, но в реальности как-то не встречалось. Имхо, кроме путаницы это ничего больше не создает и все стараются переводить имена файлов в нижний регистр.
+1
На windows машине не компилировалось ядро Linux (мда уж, явно не типичный случай) в подсистеме WSL из-за того, что несколько исходников ядра (net/netfilter/xt_hl.c и net/netfilter/xt_HL.c) имели одинаковые имена с разным регистром. Хотел уже написать, не получится ли такой курьезной ситуации, что из под Линукса нельзя (без ошибок, во всяком случае) откомпилировать его же, впрочем тут уже написали, что по умолчанию case-insensitive флаг выключен.
0

Еще как создает, когда у кого-то из разработчиков оно используется, а потом у тебя не работает.
Под маком поставил флаг case-sensitive, и часть програм у меня не работала.

0
Android и Samba. Обычным пользователям это, вообще говоря, нафиг не нужно, но для NAS'а — это спасение. Раньше то же самое эмулировалось, но это очень дорого (в смысле скорости), а главное — ненадёжно.

P.S. Только не надо прям щаз бенчмарки пускать. Понятно, что ещё потребуется какое-то время для того, чтобы перейти от эмуляции к нативному решению. А сейчас вы этой поддержкой всё только замедлите: вначале ядро будет делать всё необходимое для поддержки case-insensitivity, а потом — Samba… второй раз.
Only those users with full accounts are able to leave comments.  , please.