А что мешает собирать 32-битный wine в пакет wine32, 64-битный в wine64, а в wine поставлять скрипт, который выбирает нужные бинарники на ходу?

LD_LIBRARY_PATH + LD_32_LIBRARY_PATH

Зачем вводить LD_32_LIBRARY_PATH? Разве нельзя сразу в LD_LIBRARY_PATH перечислить нужные библиотеки? 32-битная библиотека не загрузится в 64-битный процесс, поэтому загружатор продолжит искать, пока не найдёт 64-битную версию библиотеки.

А что мешает собирать 32-битный wine в пакет wine32, 64-битный в wine64, а в wine поставлять скрипт, который выбирает нужные бинарники на ходу?

Мне мешает то, что я не до конца понимаю как работает система портов и соответственно как их нужно модифицировать чтобы реализовать Ъ-мультилиб. Что мешает текущим контрибьюторам я тоже не знаю, да и не интересовался.

Разве нельзя сразу в LD_LIBRARY_PATH перечислить нужные библиотеки?

Нельзя (к этому я вернусь), потому что:

32-битная библиотека не загрузится в 64-битный процесс

И наоборот: 64-битная библиотека не может быть загружена в 32-битный процесс.

Зачем вводить LD_32_LIBRARY_PATH?

Затем, что i386-wine никогда не будет смотреть в LD_LIBRARY_PATH, потому что он 32-битный (не мультилиб 32+64!), а wine (amd64) никогда не будет смотреть в LD_32_LIBRARY_PATH. Потому в моём скрипте для i386 используется LD_32_LIBRARY_PATH, а для amd64 — LD_LIBRARY_PATH.

А что мешает собирать 32-битный wine в пакет wine32, 64-битный в wine64, а в wine поставлять скрипт, который выбирает нужные бинарники на ходу?

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

но он не решает проблему с миксом PE32 (Intel 80386) + PE32+ (x86-64)

Что-что не решает?

Ситуации, когда PE32 пытается дёрнуть PE32+ и наоборот.

https://github.com/freebsd/freebsd-src/blob/4fe925b81e75b5885ec6d504c6217f848439164a/libexec/rtld-elf/paths.h#L34-L40

https://github.com/freebsd/freebsd-src/blob/4fe925b81e75b5885ec6d504c6217f848439164a/libexec/rtld-elf/rtld.c#L343-L359

https://github.com/freebsd/freebsd-src/blob/4fe925b81e75b5885ec6d504c6217f848439164a/libexec/rtld-elf/rtld.c#L596

Бинарники дергаются не напрямую, а через wineserver. Следовательно, нужно запускать wine и wine64 через один wineserver, тогда они будут взаимодействовать без проблем. Для этого, в свою, очередь, нужно собирать 32-бита и 64-бита из одной версии Вайна (чтобы проходила проверка версии RPC-протокола, через который компоненты общаются с сервером) и выбросить 32-битный wineserver нахер (ну или переименовать). Пример валяется вот здесь: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255381.

i386-wine никогда не будет смотреть в LD_LIBRARY_PATH, потому что он 32-битный

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

Поэтому можно делать вот так и не париться:

me@laptop:/tmp/1$ ls
итого 12
-rw-r--r-- 1 1000 1000 120 мая 19 21:11 app.c
-rw-r--r-- 1 1000 1000 105 мая 19 21:02 lib32.c
-rw-r--r-- 1 1000 1000 105 мая 19 21:03 lib64.c
me@laptop:/tmp/1$ cat app.c 
#include <stdio.h>
#include <dlfcn.h>

int main(void) {
  printf("app\n");
  dlopen("liba.so", RTLD_NOW);
  return 0;
}
me@laptop:/tmp/1$ cat lib32.c 
#include <stdio.h>

__attribute__((constructor))
static void ctor(void) {
    printf("ctor 32 bit\n");
}
me@laptop:/tmp/1$ cat lib64.c 
#include <stdio.h>

__attribute__((constructor))
static void ctor(void) {
    printf("ctor 64 bit\n");
}
me@laptop:/tmp/1$ mkdir 32 64
me@laptop:/tmp/1$ gcc -shared -o 64/liba.so lib64.c
me@laptop:/tmp/1$ i686-linux-gnu-gcc-10 -shared -o 32/liba.so lib32.c 
me@laptop:/tmp/1$ ls 32 64
32:
итого 16
-rwxr-xr-x 1 1000 1000 15172 мая 19 21:15 liba.so

64:
итого 16
-rwxr-xr-x 1 1000 1000 15984 мая 19 21:15 liba.so
me@laptop:/tmp/1$ gcc app.c -o app64 -ldl
me@laptop:/tmp/1$ i686-linux-gnu-gcc-10 app.c -o app32 -ldl
me@laptop:/tmp/1$ 
me@laptop:/tmp/1$ 
me@laptop:/tmp/1$ export LD_LIBRARY_PATH=/tmp/1/32:/tmp/1/64
me@laptop:/tmp/1$ ./app32 
app
ctor 32 bit
me@laptop:/tmp/1$ ./app64
app
ctor 64 bit
me@laptop:/tmp/1$ 

Пока что не могу понять, зачем в FreeBSD решили ввести LD_32_LIBRARY_PATH, а не расширить смысл LD_LIBRARY_PATH.

Пока что не могу понять, зачем в FreeBSD решили ввести LD_32_LIBRARY_PATH, а не расширить смысл LD_LIBRARY_PATH.

Ну, это логично, ибо lib32 хранится отдельно от lib64. Пусть и не очевидно, но в случае с общим для всех архитектур мультилиба LD_LIBRARY_PATH получается каша.

Во FreeBSD amd64 есть /lib, /usr/lib, /usr/lib32, /usr/local/lib и /usr/local/lib32, помимо этого есть /libexec, /usr/libexec (там лижат не только либы) и /usr/local/libexec (не только либы).

// Для небздунов поясню что все пакеты устанавливаются в /usr/local (в других *BSD другие пути), не смешиваясь с базовой системой.

А нафиг он нужен? Вот кстати в manjaro по дефолту мультилиб подключен(для стрима и т.п. походу). Когда его вырубаешь оно радостно бежит обновляться, обновляет libc и после этого перестает работать даже pacman)) В обычном арче кстати IIRC в pacman.conf стояло что-то типа Hold=pacman т.е. такого не должно было случиться. Понятно что это всё решается загрузкой с флейшки и починкой оттуда, но осадочек.

это логично

Ого, в первый раз вижу Стокгольмский синдром столь явно. В Debian сполна наелись боли от /lib32, доработали gnu triplets для устранения неоднозначностей, и сейчас вроде всё не так плохо. А в FreeBSD, получается, решили те же шишки собрать? Идеи не ограничиваются лицензией GPL, их можно и в BSD использовать.

Чтобы понять, насколько странным является решение добавить lib32, оставив lib для текущей архитектуры, достаточно представить себе процессор, который поддерживает одновременно инструкции RISC-V, MIPS и ARM. В наше время в этом нет ничего сверхстранного, процессоры клепают все, кому не лень. В Debian в системе библиотеки будут лежать по директориям /lib/riscv64-linux-gnu/, /lib/aarch64-linux-gnu/, /lib/mips64el-linux-gnuabi64. Во FreeBSD придётся придумывать всё заново.

Или, например, собирается софт под ARM. Система сборки не особо умная, и пытается запускать вспомогательные бинарники во время сборки, а бинарники собраны под ARM. В Debian это может сработать при использовании qemu. Библиотеки для ARM можно поставить прямо в текущую систему, а вызов qemu настроить через binfmt. Для подхода в FreeBSD придётся придумывать что-то ещё.

Так что нет, никак не верится, что подход FreeBSD логичный. Хотя бы потому, что он не однородный.

Так что нет, никак не верится, что подход FreeBSD логичный. Хотя бы потому, что он не однородный.

В Linux всё в кучу, и пакеты ставятся в /, и либы размазаны по /lib и /usr/lib тупо рандомно, без какой-либо стандартизации и/или логики, и вообще не понятно кто на ком стоял. Это не нормально в мире BSD.

В Debian сполна наелись боли от /lib32, доработали gnu triplets для устранения неоднозначностей, и сейчас вроде всё не так плохо.

Настолько неплохо, что из Убунту поддержку 32-бит пакетов собирались выкинуть вообще. (Потому что это все прибито гвоздями к сборке i386 дистрибутива.)

Или, например, собирается софт под ARM. Система сборки не особо умная, и пытается запускать вспомогательные бинарники во время сборки, а бинарники собраны под ARM. В Debian это может сработать при использовании qemu. Библиотеки для ARM можно поставить прямо в текущую систему, а вызов qemu настроить через binfmt. Для подхода в FreeBSD придётся придумывать что-то ещё.

Для этого есть jail’ы. Не самый умный способ, но придумывать ничего не надо. Один хрен современный Линукс ползет в этом же направлении.

Так что нет, никак не верится, что подход FreeBSD логичный. Хотя бы потому, что он не однородный.

Подход и не должен быть однородный. Предположение, что кому-то может понадобиться запускать, к примеру, разные сборки LibreOffice на каждый отдельный день недели в сущности абсурдное хотя бы из-за разницы в скорости исполнения родной и эмулируемых архитектур. В итоге из реальных (а не воображаемых) целей мы имеем только программы без исходников (+ зависимости для их запуска) и установку библиотек для кросс-компиляции. Программ без исходников под FreeBSD не так уж много.

В Linux всё в кучу, и

… «уши у них холодные». Да-да, я понял, что проповедники FreeBSD успешны в деле промывания мозгов.

либы размазаны по /lib и /usr/lib тупо рандомно

$ ls -ld /lib
lrwxrwxrwx 1 root root 7 сен 22  2019 /lib -> usr/lib

$ ls -ld /bin
lrwxrwxrwx 1 root root 7 сен 22  2019 /bin -> usr/bin
$ 

Это не нормально в мире BSD.

BSD это такой же набор костылей, которые тянутся из прошлого. Только одна директория /usr чего стоит. Там нет логики, и флексовать *BSD перед GNU/Linux совершенно нечем. /usr/home? /usr и так был для домашних директорий. Делать /usr/home так же глупо, как и делать /home/home/$username, потому что а зачем? Разница между /usr и /usr/local имела смысл для систем, у которых корень по NFS монтировался. Много FreeBSD инсталляций работает с корнем на NFS?

Или вот ещё про логичность устройства иерархии ФС. Развернул VPS’ку с FreeBSD для экспериментов. Лажу по директориям, вижу gdb. В /usr/libexec/gdb. Серьёзно? В libexec? В системе стоит gdb, но в PATH нет к нему пути. Это не логика. Это хейтерство GNU в чистом виде. Там боятся пустить gdb в /usr/bin или /bin, потому что он под GPL?

Ни в коем случае не пытаюсь сказать, что в GNU/Linux всё логично. Там жесть.

Только одна директория /usr чего стоит.

Лолшто? В hier(7) описано что творится в /usr, оно ровно так и творится (потому что сторонний софт туда не лезет). Единственное, что я притащил в /usr — /usr/home (потому что он там исторически был, и меня это всегда устраивало, а в Linux systemd принудительно создаст /home, и ему насрать что решил админ).

/usr/home?

По дефолту не. При этом в hier(7) про /home//usr/home упоминаний нет вообще, потому что его расположение решает админ (я даже видел пару раз /var/home).

Много FreeBSD инсталляций работает с корнем на NFS?

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

Разница между /usr и /usr/local имела смысл для систем, у которых корень по NFS монтировался.

В /usr/local устанавливается софт из пакетов/портов. Мухи отдельно, котлеты отдельно.

При монтировании по сети имеет смысл разделять /var, так как это общесистемные кэши, "домашние директории" многих демонов и прочее.

Лажу по директориям, вижу gdb. В /usr/libexec/gdb. Серьёзно? В libexec? В системе стоит gdb, но в PATH нет к нему пути.

А сейчас его в базе вообще нет (предлагается устанавливать из пакетов или собирать из портов). ☺ За всю жизнь на FreeBSD не приходилось пользоваться gdb (даже когда он был) ни разу, за всю жизнь на Linux я использовал его всего один раз. Дебаг нужен не всем, и кому он нужен регулярно, давно сделали ln -s /usr/libexec/gdb ~/bin/gdb.

---

Почему-то линуксоиды при попытке тыкать нелинукс негодуют почему там не так как в линукс. ☺

// Я не противник GNU и/или GPL (с оговоркой что не пишу код под GPL), но всегда рад насрать в душу фанатикам-сектантам, не признающим ничего кроме. ☺

Интересно — проверь.

Лолшто? В hier(7) описано

Ты когда-нибудь задумывался, что значит usr? Вот bin от слова binaries, lib от libraries, а usr что значит?

Много. По крайней мере больше чем Linux.

Откуда данные? С потолка?

В /usr/local устанавливается софт из пакетов/портов. Мухи отдельно, котлеты отдельно.

/usr/local появился для софта, который жил на дисках локальной машины. Поэтому «local». Во FreeBSD этот смысл потерялся.

сейчас его в базе вообще нет

Вот смешно будет с /usr vs. /usr/local, когда базовую систему нарежут на пакеты. Если всё будет в пакетах, включая базовую систему, всё должно ставиться в /usr/local, так? Тогда /usr/bin, /usr/lib и прочие будут пустыми.

Дебаг нужен не всем, и кому он нужен регулярно, давно сделали ln -s /usr/libexec/gdb ~/bin/gdb.

Это не логично. Это просто тупо. Тут оправданий просто нет.

Почему-то линуксоиды при попытке тыкать нелинукс негодуют почему там не так как в линукс.

Тебя убедили, что FreeBSD это Unix(-like), поэтому если там что-то сделано определённым образом, то это правильно, логично и божественно. Всё остальное богохульство. А если кто-то указывает на бардак, это фанатики линукс.

но всегда рад насрать в душу фанатикам-сектантам

Если ты делаешь это с использованием головы, значит говно у тебя там? Зачем ты забил свою голову говном?

В /usr/libexec/gdb. Серьёзно?

Занятно. (В FreeBSD 13 его уже нет.) Еще чуть раньше gdb определенно устанавливался в /usr/bin. Суть в том, что это очень-очень старый (GPL2) gdb, ему на замену притащен lldb, и если кому-то нужен именно gdb, им нужно ставить свежую версию из портов.

См. https://github.com/freebsd/freebsd-src/commit/a52b0bb1d2db8eb6a8337a606c7069b9d4407d1b

Откуда данные? С потолка?

От знакомых бздунов, коих немало. Плюс я сижу на официальном канале на фриноде.

Во FreeBSD этот смысл потерялся.

Он просто изменился. Загрузка ОС по сети с использованием локального хранилища это как-то странно. Обычно либо всё по сети, либо всё локально.

базовую систему нарежут на пакеты

Не нарежут, потому что это не Linux.

Тебя убедили, что FreeBSD это Unix(-like)

Во-первых BSD != UNIX, хоть и UNIX-like, FreeBSD от BSD отличается не меньше, чем BSD от UNIX. Во-вторых меня никто ни в чём не убеждал, я с FreeBSD познакомился раньше чем с Linux (хоть и не использовал на десктопе до недавнего времени).

это фанатики линукс

Не вся критика от противников. ^_~

Если ты делаешь это с использованием головы, значит говно у тебя там? Зачем ты забил свою голову говном?

Если задело, значит фанатик. ^_~

несмотря на всю стройность базовой системы..

весь линуксячий бардак весело перекатывается в /usr/local

И там действительно всё плохо, так как по каждому чиху приходится нырять в /usr/local/etc

UFS2 просто хорошая надёжная ФС, ни больше ни меньше. И не слушай байки о потере файлов, необратимых повреждениях etc, за 10 лет, что я на FreeBSD ни разу такого не было. А вот с ext4 было.

Не нарежут, потому что это не Linux.

Разве PkgBase потеряла актуальность?

Не нарежут, потому что это не Linux.

Разве PkgBase потеряла актуальность?

Ему до состояния, готового к использованию, ещё очень далеко. А за это время всё может очень сильно поменяться. Сколько всего так же пилили-пилили, недопилили и выкинули…

От знакомых бздунов, коих немало. Плюс я сижу на официальном канале на фриноде.

Заявления уровня «среди моих знакомых никто не пользуется FreeBSD, поэтому им никто не пользуется». Серьёзно не видишь в подобном мышлении никаких проблем?

Он просто изменился. Загрузка ОС по сети с использованием локального хранилища это как-то странно. Обычно либо всё по сети, либо всё локально.

Он потерялся. Когда в local ставили софт локально, имело смысл называть директорию local. Если во FreeBSD туда ставят порты, имеет смысл называть эту директорию ports. Но ports занято под дерево портов, которое по сути является сборником поверхностных (shallow) исходников. Куда логичнее держать его в src/ports. Но так не принято, потому что вся иерархия директорий это набор костылей, которые тянутся из прошлого. Во многих местах там нет смысла. Ты просто привык, и поэтому считаешь это правильным.

Кстати, про usr. Это от users. В директории /usr лежали домашние директории пользователей. Использовать /usr/john для домашней директории пользователя john вполне логично, потому что если пользователей много, а их директории будут лежать в корне, там будет твориться жесть. А вот использовать /usr/home — не логично. Так сделали из-за того, что в usr прочно обосновались bin, share, lib и так далее. Почему они там обосновались? Потому что на одной из старых Unix машин перестало хватать места на корневом разделе, и кто-то там решил проблему, создав bin в /usr разделе. Набор костылей.

Это какой-то религиозный культ. Поклонение костылям.

Если задело, значит фанатик. ^_~

Это «испанский стыд», только и всего.

Ему до состояния, готового к использованию, ещё очень далеко.

Тем не менее, проект не считается заброшенным, а значит желание разделить на пакеты есть.

Сколько всего так же пилили-пилили, недопилили и выкинули

Было бы у них достаточно человеческих ресурсов, во FreeBSD и аналог systemd запилили бы. Очень вероятно, что и запилят.

Вообще то /usr это не users, а Universal System Resources.

Потому что на одной из старых Unix машин перестало хватать места на корневом разделе

Это как? Количество записей в директории ФС ограничено? Или монтировать /usr с отдельного раздела было строго обязательно?

Есть ли Live графическая среда прямиком из установщика, как из убунты?

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

Заявления уровня

Это наблюдение. Я часто хожу в цирк на ЛОР и в террариум IRC. Второе — вполне себе источник актуальной информации по фре. ☺

набор костылей, которые тянутся из прошлого

Ты сразу по достижении совершеннолетия сменил вероисповедание, фамилию/имя/отчество, пол и гражданство? ☺ Корни не выбирают! ^_~

желание

Одного желания мало.

Это как?

http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

Вообще то /usr это не users, а Universal System Resources.

И ведь есть те, кто в это свято верит! Правда, я слышал только про расшифровку «UNIX System Resources». В любом случае, ls и cat, получается, не универсальные ресурсы, да?

Хм. Плохо, что только у usr есть расшифровка, а у остальных нет. Можно же что-нибудь придумать:

bin — «broken imperceptible nursery»
etc — «enormously tremendous clutter»
lib — «lax idiomatic backbone»

Могли бы SMF из солярки утащить. dtrace и zfs же утащили?

Могли бы SMF из солярки утащить.

Это пол ядра переписывать.

bin

best in next

etc

every time content

lib

library important binaries

var – very active resourses

root – random open output tree

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

указание очевидной ошибки

В чём ошибка-то?

Да уже ничего не логично. Ты давно во фряхин /usr/local заглядывал?

Там помойка образуется. похлеще линуксовой. Причем пакеты так собираются, что приходится часто руками в конфиги лазить, чтобы одно интегрировать с другим. Извините, но среднестатистический юзверь,админ не мега-гига-мозг, чтобы помнить всякую хрень в сотенных количествах. Тот же Гном3 сконфигурировать для запуска - понырять нужно по конфигам.

И да, панимаишь ли, кроме Wmaker/Icewm/tile-wm - больше не осталось никаких легких оконных систем для ежедневного использования. Стоит ли возня с Фрёй ради делания копии линукса, только в /usr/local?

Ты давно во фряхин /usr/local заглядывал?

Регулярно заглядываю.

Там помойка образуется. похлеще линуксовой.

Ну, логично. В Linux пакеты размазываются в /, помойка по всей системе; во FreeBSD пакеты/порты ставятся в /usr/local, там помойка.

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

Никто не обещал интеграции пакетов. Пакеты — это зоопарк.

Стоит ли возня с Фрёй ради делания копии линукса, только в /usr/local?

Если тебе нужна копия Linux, юзай Linux. А делать из одного другое — пустая трата времени.

Делать Linux из Linux считается маргинальством. «Пусть этим занимаются дистрибутостроители, а мы лишь будем выбирать подходящий Linux», - говорят они.

Ну что не так? тебе заняться больше нечем, как только сидеть и настраивать ФриБСД во ФриБСД?

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

Т.е. вожделенная кнопочка «сделать всё зашибись» всё еще актуальна. А при маркетингово-критическом сравнении, так у Фри уже нет преимущества в пользовательской части.

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

Тогда плати за Windows и не возмущайся. =P

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

Еще одна новость из прошлого мира...

https://pcem-emulator.co.uk/phpBB3/viewtopic.php?f=2&t=3708

Создатель(ница) PCem собралась на покой, вернее устраниться от проекта, так как он его(её) высосал и надо отойти. В принципе понятно.

Но таки подарила всем желающим немножко минут соприкосновения с молодостью. Как Мери Поппинс прям таки, усадила всех на карусель.

В принципе у меня достаточно стабильно работает, чтобы запустить Вин98 с полным фаршем всего от Дельфей до Автокада.

Побаловался и Шапкой 6.2.

А кто в игрушки рубился - тому вообще исполнение всех влажных мечт.

Ни в коем случае не пытаюсь сказать, что в GNU/Linux всё логично. Там жесть.

А где не жесть? Да чтобы ещё и пользоваться удобно было?
А так ты совершенно прав. Кто давал правильное русло - умер. Везде умер. Теперь во все стороны бардак.

Конкуренты тоже кушать хотят.

Ну что не так? тебе заняться больше нечем, как только сидеть и настраивать ФриБСД во ФриБСД?

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

Что-что не так? У меня хобби: ковыряться во FreeBSD. Почему нет-то? Не совпадает с твоими устремлениями и развлечениями — проходи мимо. Система для вдумчивых людей.

Установил FreeBSD 13-STABLE на чистый носитель методом

cd /usr/src/ && make installworld installkernel distribution DESTDIR=/mnt

Скопировал /usr/src, /usr/ports, /var/db/ports, /usr/local, /var/db/pkg.

Настроил систему и запустил уже с нового носителя.

Захотелось обновить установленные пакеты:

% pkg upgrade
Updating roxy repository catalogue...
Fetching meta.conf: 100%    163 B   0.2kB/s    00:01    
Fetching packagesite.txz: 100%  166 KiB 169.7kB/s    00:01    
Processing entries:   5%
pkg: wrong architecture: FreeBSD:12:amd64 instead of FreeBSD:13:amd64

Как так-то?!

% cat /etc/pkg/FreeBSD.conf
# $FreeBSD$
#
# To disable this repository, instead of modifying or removing this file,
# create a /usr/local/etc/pkg/repos/FreeBSD.conf file:
#
#   mkdir -p /usr/local/etc/pkg/repos
#   echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf
#

FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}

% cat /usr/local/etc/pkg/repos/FreeBSD.conf
cat: /usr/local/etc/pkg/repos/FreeBSD.conf: No such file or directory

Не знаю, я STABLE юзал не меньше пяти лет назад на headless в виртуалке, и обновление там не требовалось по задаче (накатил, настроил, работает). А с CURRENT (метод обновления тот же) я задолбался на десктопе уже через две недели, потому перекотился на RELEASE.

Но даже со STABLE имеет смысл юзать ZFS BE. ^_~