Поздравляю, это говно пытается ставиться в / в обход sandbox
Вариантов несколько:
1) если билдсистема безнадежное говно - ставить все файлы руками. Да, боль. Но иногда это единственный способ;
2) если в билдсистеме есть ключ(а-ля DESTDIR) - указать его равным ${D} - и тогда всё будет ставится куда надо;
3) если билдсистема говно, но простая и читабельная - пропатчить чтобы поддерживала DESTDIR, далее смотри пункт 2);
Окей, это я про блендер имел в виду. Свежайший в дереве это релиз октября 2014 года. Бампы делаются, но после назначения на hasufell на них просто забивают. Ему плевать вообще, 2.76b (вышедший 3 ноября 2015 года) так и не попал в дерево, движения прекратились в январе, хотя там люди и патчи и всякий треш дописывали.
2.77 я бампнул завтра неделя как, есть готовый ебилд в nightmare, прекрасно работает и собирается, чуваку всё что нужно, это заапрувить, но нет, ему плевать. Он даже CONFIRMED поставить не может, лол.
Да. И это dumb way, то есть с каждым бампом надо следить - а не поменялся ли состав устанавливаемых файлов. То есть к нему стоит прибегать, только если по другому никак
Кстати в порядке оффтопика - не думал перейти на thin-манифесты? git один хрен хранит чексуммы коммитов, хранить их для ебилдов еще и в Manifest - это оверкилл.
Включаются они просто. После этого надо пройтись по всем пакетам с ebuild ... digest. Или можно запустить на корень оверлея repoman manifest
при thin manifest в манифесте остаются только записи тарболлов с исходниками. Чексуммы ебилдов там не сохраняются.
Профит:
1) при изменении ебилда(без изменения SRC_URI), если забыл обновить манифест -> не страшно, потому что он и так не изменится;
2) в случае виртуальных пакетов(где вообще нет SRC_URI) - Manifest вообще будет отсутствовать;
3) меньше нагрузка на пакетный менеджер - он не будет проверять чексумму на ебилд;
Недостатки:
1) необходимо получать изменения из системы контроля версий, где целостность файлов гарантируется сторонним механизмом. Git подходит, CVS(которая была раньше в Gentoo) - нет.