Com base nos comentários de @likewhoa acima, a estrutura do ebuild precisava ser massageada. Os criadores não tinham uma estrutura de portage recente em mente ao criar seus repositórios git.
Para linha de comando
(um ebuild sem estrutura de diretórios do portage)
Em /usr/local/portage/
, decidi que snap-confine pertencia à categoria sys-apps
Do prompt de raiz do bash:
cd /usr/local/portage
git clone https://github.com/zyga/snap-confine-gentoo.git
cd snap-confine-gentoo
mkdir -pv sys-apps/snap-confine
# the Manifest file will be recreated later
rm -v Manifest
mv -v snap-confine-1.0.32.ebuild sys-apps/snap-confine/
# to avoid errors, you need your masters = gentoo reference
mkdir -v metadata
echo 'masters = gentoo' > metadata/layout.conf
cd sys-apps/snap-confine
ebuild snap-confine-1.0.32.ebuild manifest clean merge
Como se constatou, o .ebuild não foi formado adequadamente com dependências corretas, mas acho que essas etapas fornecem um bom tutorial baseado em:
Para gerenciamento do Portage
Baseado em outros repositórios do Gentoo, eu recomendei ao desenvolvedor que criasse um repositório único contendo as ebuilds snap-confine e snapd sob as categorias de pacotes sys-apps
e app-emulation
, respectivamente.
Em seguida, criamos um arquivo metadata / layout.conf contendo masters = gentoo
para evitar reclamações de compatibilidade do portage. A orientação do desenvolvedor também exige que tenhamos um arquivo profiles / repo_name com o nome do repo identificado. Na pasta de cada pacote, criamos um arquivo metadata.xml e, em seguida, executamos o repoman manifest
para gerar o arquivo Manifest .
Por último, um usuário precisa criar uma entrada em /etc/portage/repos.conf/
, cujas instruções são detalhadas em sakaki-tools repo do github