View source for Argent Portage Central Configuration

=== System Administration ===

This is the system administration sequence, starting with the heart of every Gentoo based system: '''/etc/portage'''.

First, something you have to know: '''Argent is a complete Gentoo.''' Same portage, same ebuilds, same profiles, same USE flags, same <code>/etc/portage</code>, with every regular Gentoo feature. What Argent adds on top is a central configuration, a binhost built with that configuration, and tools like <code>epkg</code> and <code>avasile</code> to keep your system in line with them.

So everything the Gentoo documentation says applies to Argent too, and you should read it before you touch <code>/etc/portage</code>:

* [https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Portage Gentoo Handbook: Portage], how portage works, how it syncs, how it installs and updates packages
* [https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/USE Gentoo Handbook: USE flags], what USE flags are, global and per package, how to set them
* [https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Features Gentoo Handbook: Portage features], the <code>FEATURES</code> variable in make.conf, like <code>buildpkg</code>, <code>parallel-fetch</code> or <code>splitdebug</code>

This page only explains what is different on Argent.

== How /etc/portage works on Argent ==

On Argent, <code>/etc/portage</code> is a git directory. Actuall a symlink to a git repo:

<code>/etc/portage -> /opt/argentws-build/conf/intel/portage</code>

and <code>/opt/argentws-build</code> is a git clone of our central configuration repository:

<code>https://gitlab.com/argent/argentws-build.git</code>

<code>avasile</code> sets this up for you when you switch modes (<code>--usermode</code>, <code>--devmode</code>, <code>--srcmode</code>). The only thing that changes between modes is which make.conf is active:

<code>/etc/portage/make.conf/00-main.conf -> make.conf.amd64-user</code> (user mode)

<code>/etc/portage/make.conf/00-main.conf -> make.conf.amd64-devel</code> (devmode)

<code>/etc/portage/make.conf/00-main.conf -> make.conf.amd64-srcmode</code> (srcmode)

To see which mode you are on:

<code>readlink -f /etc/portage/make.conf/*</code>

== Why is /etc/portage under git ==

Because '''the binary packages on our binhost are built with exactly this configuration'''. The USE flags, keywords, masks and make.conf you have are the same ones our build server used. If your configuration drifts away from it, the binaries stop matching your system, and portage starts compiling things you didn't ask for (or, in user mode, silently ignores what you changed).

So git gives us:

* every Argent machine has the same configuration, the one the binaries were built with
* one <code>epkg update</code> brings you the new configuration together with the new packages
* every change we make is public, with history, on gitlab (for now)
* switching modes is just changing one symlink

== What epkg update does to /etc/portage ==

At every <code>epkg update</code>, <code>/opt/argentws-build</code> is reset to exactly what is on our server:

<code>git fetch --depth=1 origin master && git reset --hard origin/master && git clean -fd</code>

This means:

* '''any change you make to an Argent file is lost''' at the next update
* any new file of yours that git doesn't ignore is '''deleted''' at the next update
* files that git ignores are left alone, and this is where your own configuration goes

<code>epkg devsync</code> does a plain <code>git pull</code> instead. If you changed an Argent file, the pull stops with a conflict, and you have to restore the file (see below) before it can continue.

== Argent files and your files ==

Every directory in <code>/etc/portage</code> has a <code>.gitignore</code> that works as a whitelist: it ignores '''every file with a dot in its name''' (<code>*.*</code>), except the Argent files, which are listed one by one.

The Argent files start with <code>00-</code>, like <code>00-argent.package.use</code>. Don't edit them.

Your files:

* must have a dot in their name, otherwise git doesn't ignore them and <code>epkg update</code> deletes them
* should start with a bigger number than <code>00-</code>, so they are read after ours and win over them

The convention is <code>100-my.<something></code>:

<code>/etc/portage/package.use/100-my.package.use</code>

<code>/etc/portage/package.accept_keywords/100-my.package.keywords</code>

<code>/etc/portage/package.mask/100-my.package.mask</code>

<code>/etc/portage/package.unmask/100-my.package.unmask</code>

<code>/etc/portage/package.env/100-my.package.env</code>

<code>/etc/portage/make.conf/01-my.make.conf</code>

'''Don't name a file <code>00-my.package.keywords</code>''', that name is on the Argent whitelist, so git doesn't protect it.

'''Keep a copy of your files before you switch modes.''' <code>avasile --usermode</code>, <code>--devmode</code>, <code>--srcmode</code> and <code>--custom</code> delete the whole <code>/opt/argentws-build</code> and clone it again, and your files go away with it. <code>epkg update</code> doesn't do this, only a mode switch does.

== make.conf ==

<code>make.conf</code> is the main configuration of portage. It's where Gentoo keeps the settings for the whole system:

* how packages are compiled: <code>COMMON_FLAGS</code>, <code>CFLAGS</code>, <code>CXXFLAGS</code>, <code>MAKEOPTS</code>
* the global USE flags: <code>USE</code>, and the USE flags written as variables, like <code>VIDEO_CARDS</code>, <code>L10N</code>, <code>PYTHON_TARGETS</code>
* how portage behaves: <code>FEATURES</code>, <code>EMERGE_DEFAULT_OPTS</code>
* where things are kept: <code>PKGDIR</code> (binary packages), <code>DISTDIR</code> (sources), <code>PORTDIR</code> (the portage tree)
* which licenses you accept: <code>ACCEPT_LICENSE</code>, and where sources are downloaded from: <code>GENTOO_MIRRORS</code>

It's written like a shell script, <code>VARIABLE="value"</code>, and a variable can use another one, like <code>CFLAGS="${COMMON_FLAGS}"</code>. The Gentoo documentation is [https://wiki.gentoo.org/wiki//etc/portage/make.conf here], and all the variables are in:

<code>man make.conf</code>

=== make.conf as a directory ===

On Gentoo, <code>/etc/portage/make.conf</code> can be a single file or a directory. When it's a directory, portage reads every file in it in alphabetical order, as if they were one big make.conf, and when the same variable is set twice, the last one wins.

Argent uses it as a directory. The main file is a symlink to our make.conf for the mode you are on:

<code>/etc/portage/make.conf/00-argent.conf -> /opt/argentws-build/conf/intel/portage/make.conf.amd64-devel</code>

(or <code>00-main.conf</code>, same thing)

'''The main file must be called <code>00-argent.conf</code>, <code>00-main.conf</code> or <code>main.conf</code>'''. These are the names <code>epkg</code> looks for, if it can't find one of them, <code>epkg</code> fails to run. Don't rename it, and don't replace it with your own.

The three Argent make.conf files are the same, except for how they use the binhost:

* <code>make.conf.amd64-user</code>: <code>--getbinpkgonly</code>, only binaries
* <code>make.conf.amd64-devel</code>: <code>--getbinpkg</code> and <code>FEATURES=buildpkg</code>, binaries when they match, compile and save the binary when they don't
* <code>make.conf.amd64-srcmode</code>: no binhost, compile everything and save the binaries

=== Your own make.conf ===

Next to ours, you can keep your own:

<code>/etc/portage/make.conf/01-my.make.conf</code>

It's read after ours, so whatever you set there wins. The whole <code>make.conf</code> directory is ignored by git, so <code>epkg update</code> leaves it alone. For example:

<pre>
MAKEOPTS="-j16"
VIDEO_CARDS="amdgpu radeonsi"
L10N="en en-US ro ro-RO"
USE="${USE} -wayland"
</pre>

Things to know:

* <code>MAKEOPTS</code>, <code>COMMON_FLAGS</code> and the other compiler settings only matter for what you compile yourself. If you use <code>-march=native</code>, what you compile (and what gets saved in <code>/var/cache/binpkgs</code>) runs only on your CPU
* everything that changes USE flags (<code>USE</code>, <code>VIDEO_CARDS</code>, <code>L10N</code>, <code>PYTHON_TARGETS</code>, ...) means compiling in devmode, and has no effect in user mode, see [[#USE flags|USE flags]] below
* don't change <code>PORTDIR</code> or <code>GENTOO_DISTRO</code>, <code>epkg</code> depends on them

'''The moment you do this, you are deriving away from Argent.''' Your system is no longer the one our binaries were built for, and we can't help you anymore with the issues specific to your setup. But that's what Gentoo is in the end: your system, your configuration, and back to reading the documentation.

=== make.conf.local ===

<code>/etc/portage/make.conf.local</code> is '''not''' a portage file, portage never reads it. Only <code>epkg</code> reads it, right after the main make.conf, so whatever you put there overrides the main make.conf, for <code>epkg</code> only. <code>avasile</code> and <code>epkg</code> create it empty.

Today it matters only for the few variables <code>epkg</code> reads directly from make.conf when it starts, like <code>PORTDIR</code> and <code>GENTOO_DISTRO</code>. <code>PKGDIR</code> is not one of them, <code>epkg</code> asks portage for it, so setting it in your <code>01-my.make.conf</code> is enough. Most users should leave <code>make.conf.local</code> empty.

== USE flags ==

The global USE flags live in the active make.conf (<code>make.conf.amd64-user</code>, <code>make.conf.amd64-devel</code>, ...), grouped by topic: <code>SYSTEM_USE</code>, <code>CODECS_USE</code>, <code>MEDIA_USE</code>, <code>SOUND_USE</code> and so on. The per package USE flags live in <code>/etc/portage/package.use/00-*.package.use</code>.

If USE flags are new to you, read the [https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/USE Gentoo Handbook on USE flags] first, the rest of this section assumes you know what they are.

=== In user mode ===

'''Don't change USE flags in user mode.''' User mode installs only binary packages (<code>--getbinpkgonly</code>), and in this case portage doesn't check if the USE flags of the binary match yours. You get our binaries, built with our USE flags, whatever you set, so your change simply does nothing.

If you need different USE flags, switch to devmode first:

<code>avasile --devmode</code>

=== In devmode ===

Here you can change USE flags. When your USE flags are the same as ours, portage installs the binary from our binhost. When they differ, portage compiles that package for you, and saves the result in <code>/var/cache/binpkgs</code> so you don't compile it again.

To see which USE flags a package has, and which ones are active:

<code>equery uses <package></code>

To change them for one package, add a line to your own file:

<code>echo "media-video/mpv lua -wayland" >> /etc/portage/package.use/100-my.package.use</code>

To change them globally, use your own make.conf file (see [[#make.conf|make.conf]] above):

<code>echo 'USE="${USE} -wayland"' >> /etc/portage/make.conf/01-my.make.conf</code>

Keep the <code>${USE}</code> in there, otherwise you throw away all our USE flags, not only the one you wanted to change.

Then see what would be rebuilt, and do it:

<code>epkg upgrade</code>

<code>epkg upgrade</code> already rebuilds every package whose USE flags changed. For only one package:

<code>epkg src-newuse <package></code>

'''Every USE flag you change is one more package you compile yourself''', and one more package that no longer follows the binhost. Change only what you really need.

== Looking into the git ==

Since <code>/etc/portage</code> is a git repository, you can use git to see what is going on:

<code>cd /etc/portage</code>

By default you have only the last commit (<code>epkg update</code> fetches with <code>--depth=1</code>). You can see the whole history on gitlab, or bring it locally with:

<code>epkg force-sync</code>

Then, what we changed lately:

<code>git log --oneline</code>

What we changed in one file, and why:

<code>git log -p package.use/00-argent.package.use</code>

The next <code>epkg update</code> makes it shallow again.

If you changed any Argent file by mistake:

<code>git status</code>

<code>git diff</code>

To restore an Argent file you changed:

<code>git checkout -- package.use/00-argent.package.use</code>

To see your own files (the ones git ignores):

<code>git status --ignored</code>

'''Never commit anything here.''' At the next <code>epkg update</code> your commit is thrown away by the reset, together with everything in it.

== Leaving the central configuration ==

If you want <code>/etc/portage</code> fully yours, disconnected from Argent, <code>avasile</code> has the <code>--custom</code> and <code>--decentralize-*</code> modes. They are for advanced Gentoo users, read <code>avasile --help</code> carefully before using them. <code>--decentralize-gentoo</code> is a one way ticket.


=== Portage ===

Portage on Argent is the regular Gentoo portage. <code>epkg</code> is only a wrapper around it, so you can always use <code>emerge</code>, <code>equery</code>, <code>qlist</code> and the rest of the Gentoo tools directly. The mode you are on still applies: in user mode, <code>emerge</code> installs only binaries too, because <code>--getbinpkgonly</code> is set in the make.conf.

For how portage itself works, the [https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Portage Gentoo Handbook: Portage] is the reference. Below is only what Argent does differently.

== Repositories ==

Argent uses two repositories, both defined in <code>/etc/portage/repos.conf/</code>:

<code>argent-ws</code> in <code>/var/db/repos/argent-ws</code>, synced from <code>https://gitlab.com/argent/argent-ws.git</code>

<code>gentoo</code> in <code>/var/db/repos/gentoo</code>, synced from <code>https://gitlab.com/argent/portage.git</code>

<code>argent-ws</code> is the main repository (<code>main-repo = argent-ws</code>), with our own packages, our fixes and our profiles. It has a higher priority (50) than <code>gentoo</code> (1), so when both have the same version of a package, ours wins.

The <code>gentoo</code> repository is '''our snapshot of the Gentoo tree''', not the live Gentoo one, so the ebuilds you have match the binaries you get. Don't point it to the Gentoo servers, you will get ebuilds that are newer than our binaries and you'll end up compiling half of the system.

To see which one is the main repository on your system:

<code>portageq repositories_configuration / | grep main-repo</code>

In user mode, both repositories are '''minimal''': only <code>profiles</code>, <code>metadata</code> and <code>eclass</code>, no ebuilds. You don't need ebuilds to install binaries. In devmode and srcmode you get the full trees.

=== Your own overlays ===

You can add any other overlay the Gentoo way, for example with [https://wiki.gentoo.org/wiki/Eselect/Repository eselect repository]:

<code>eselect repository enable guru</code>

It writes <code>/etc/portage/repos.conf/eselect-repo.conf</code>, which has a dot in its name, so it survives <code>epkg update</code>. If you write the repos.conf file by hand, follow the same rule, like <code>/etc/portage/repos.conf/100-my-overlay.conf</code>.

Keep in mind:

* <code>epkg update</code> syncs only <code>gentoo</code> and <code>argent-ws</code>, use <code>epkg devsync</code> or <code>emaint sync -r <overlay></code> for yours
* our binhost has nothing from your overlays, everything from there gets compiled, so overlays make sense only in devmode or srcmode

=== Example: your own kernel ===

A good reason for your own overlay is your own kernel. Say you want <code>linux-argent</code> with a different kernel config. You don't edit our ebuilds (<code>epkg update</code> resets them), you clone them into your overlay under a new name.

You need devmode for this, in user mode <code>argent-ws</code> has no ebuilds to clone from:

<code>avasile --devmode</code>

'''1. Create your overlay'''

<code>eselect repository create myoverlay</code>

It lives in <code>/var/db/repos/myoverlay</code>. Our kernel ebuilds use the <code>argent-kernel</code> eclass from <code>argent-ws</code>, so your overlay has to see it. Edit <code>/var/db/repos/myoverlay/metadata/layout.conf</code>:

<pre>
masters = gentoo argent-ws
thin-manifests = true
</pre>

'''2. Clone the two ebuilds under a new name'''

The name matters: <code>linux-mykernel</code> builds a kernel called <code>6.12.110-mykernel</code>, so it installs next to <code>6.12.110-argent</code>, not over it. The sources package must be called <code>mykernel-sources</code>, the same way ours are <code>linux-argent</code> and <code>argent-sources</code>.

<code>cd /var/db/repos/myoverlay</code>

<code>mkdir -p sys-kernel/linux-mykernel/files sys-kernel/mykernel-sources/files</code>

<code>cp /var/db/repos/argent-ws/sys-kernel/linux-argent/linux-argent-6.12.110.ebuild sys-kernel/linux-mykernel/linux-mykernel-6.12.110.ebuild</code>

<code>cp /var/db/repos/argent-ws/sys-kernel/linux-argent/files/* sys-kernel/linux-mykernel/files/</code>

<code>cp /var/db/repos/argent-ws/sys-kernel/argent-sources/argent-sources-6.12.110.ebuild sys-kernel/mykernel-sources/mykernel-sources-6.12.110.ebuild</code>

'''3. Get a kernel config to start from'''

Our kernel config is inside our kernel tarball. Download it, and take the config out of it:

<code>epkg fetchsourcepkg =sys-kernel/argent-sources-6.12.110</code>

<code>tar -xJOf /var/cache/distfiles/linux-6.12.110-argent.tar.xz --wildcards '*/argent/config/argent-6.12-amd64.config' > /root/mykernel-6.12-amd64.config</code>

Change it the way you want. The easiest way is to install <code>argent-sources</code>, copy the config in there as <code>.config</code>, run <code>make menuconfig</code>, and take the <code>.config</code> back.

Then put it in both packages, with the name the eclass looks for (<code><name>-<major.minor>-amd64.config</code>):

<code>cp /root/mykernel-6.12-amd64.config sys-kernel/linux-mykernel/files/</code>

<code>cp /root/mykernel-6.12-amd64.config sys-kernel/mykernel-sources/files/</code>

'''4. Edit the ebuilds'''

Both of them still download our kernel tarball (<code>K_ROGKERNEL_SELF_TARBALL_NAME="argent"</code> stays), but they use your config instead of ours.

<code>sys-kernel/linux-mykernel/linux-mykernel-6.12.110.ebuild</code>:

<pre>
EAPI=8

K_ROGKERNEL_SELF_TARBALL_NAME="argent"
K_REQUIRED_LINUX_FIRMWARE_VER="20260622"
K_ROGKERNEL_FORCE_SUBLEVEL="110"
K_ROGKERNEL_FORCE_UPPERLEVEL="6.12"
K_ROGKERNEL_PATCH_UPSTREAM_TARBALL="0"
K_KERNEL_NEW_VERSIONING="1"

inherit argent-kernel

KEYWORDS="amd64"
DESCRIPTION="My own kernel image, based on linux-argent"
RESTRICT="mirror"
IUSE="grub2"

src_prepare() {
	argent-kernel_src_prepare
	cp "${FILESDIR}/mykernel-6.12-amd64.config" "${S}/argent/config/" || die
}
</pre>

<code>sys-kernel/mykernel-sources/mykernel-sources-6.12.110.ebuild</code>:

<pre>
EAPI=8

K_ROGKERNEL_FORCE_SUBLEVEL="110"
K_ROGKERNEL_FORCE_UPPERLEVEL="6.12"
K_ROGKERNEL_NAME="mykernel"
K_ROGKERNEL_URI_CONFIG="yes"
K_ROGKERNEL_SELF_TARBALL_NAME="argent"
K_ONLY_SOURCES="1"
K_KERNEL_NEW_VERSIONING="1"

inherit argent-kernel

KEYWORDS="amd64"
DESCRIPTION="My own kernel sources, based on argent-sources"
RESTRICT="mirror"
IUSE="grub2 sources_standalone"

DEPEND="${DEPEND}
	sources_standalone? ( !=sys-kernel/linux-mykernel-${PVR} )
	!sources_standalone? ( =sys-kernel/linux-mykernel-${PVR} )"

src_prepare() {
	argent-kernel_src_prepare
	cp "${FILESDIR}/mykernel-6.12-amd64.config" "${S}/argent/config/" || die
}
</pre>

What changed compared to ours:

* <code>K_ROGKERNEL_NAME</code> is <code>mykernel</code> in the sources ebuild (in <code>linux-mykernel</code> it comes from the package name by itself)
* the sources depend on <code>linux-mykernel</code>, not on <code>linux-argent</code>
* <code>src_prepare()</code> puts your config next to ours, inside the unpacked tarball, where the eclass looks for it

'''5. Manifest and install'''

<code>ebuild sys-kernel/linux-mykernel/linux-mykernel-6.12.110.ebuild manifest</code>

<code>ebuild sys-kernel/mykernel-sources/mykernel-sources-6.12.110.ebuild manifest</code>

<code>epkg install sys-kernel/mykernel-sources</code>

This pulls in <code>linux-mykernel</code> too, and compiles both, there is no binary for your kernel on our binhost. With <code>USE=grub2</code>, the grub menu is regenerated at the end, otherwise do it yourself:

<code>grub-mkconfig -o /boot/grub/grub.cfg</code>

And rebuild the external modules (nvidia, virtualbox, zfs, ...) for your new kernel:

<code>epkg module-rebuild</code>

'''6. Keeping it up to date'''

Your kernel doesn't follow ours anymore. When we move <code>linux-argent</code> to a new version, you copy the new ebuilds again, rename them, and put your changes back in. If the major version changes (6.12 to 6.18 for example), your config needs a new name too, <code>mykernel-6.18-amd64.config</code>, and a look with <code>make oldconfig</code>.

Keep a copy of <code>/etc/portage/repos.conf/eselect-repo.conf</code>, a mode switch with <code>avasile</code> removes it (your overlay in <code>/var/db/repos/myoverlay</code> stays).

== Binhost ==

The binary packages come from our binhost, defined in:

<code>/etc/portage/binrepos.conf/binhost-main.conf</code>

The mode decides how portage uses it:

* user mode: <code>--getbinpkgonly</code>, only binaries, never compiles
* devmode: <code>--getbinpkg</code>, binaries when they match your configuration, compiles when they don't, and saves what it compiled in <code>/var/cache/binpkgs</code> (<code>FEATURES=buildpkg</code>)
* srcmode: compiles everything

If you have your own binhost (for example a second machine that compiles for you), add it in its own file, like <code>/etc/portage/binrepos.conf/100-my-binhost.conf</code>, with its own <code>priority</code>. See the [https://wiki.gentoo.org/wiki/Binary_package_guide Gentoo binary package guide] for the format.

== Profile ==

Argent uses the Gentoo profile:

<code>default/linux/amd64/23.0/desktop/plasma/systemd</code>

<code>avasile</code> sets it at every mode switch, and our binaries are built for it. You can see it with:

<code>eselect profile show</code>

You can change it with <code>eselect profile set</code>, as on any Gentoo, but then your system no longer matches the binhost, and the next <code>avasile</code> mode switch sets it back.

On top of the profile, we have our own overrides in <code>/etc/portage/profile/</code> (<code>use.mask</code>, <code>package.use.mask</code>, <code>package.provided</code>). Those are Argent files too.

== Keywords, masks and unmasks ==

Same as on Gentoo, same rule as for USE flags: your own files, next to ours.

To accept the testing version of a package:

<code>echo "app-editors/neovim ~amd64" >> /etc/portage/package.accept_keywords/100-my.package.keywords</code>

To stop a package (or a version) from being installed:

<code>echo ">=media-video/obs-studio-32" >> /etc/portage/package.mask/100-my.package.mask</code>

To allow something that we masked:

<code>echo "=media-video/obs-studio-32.0.1" >> /etc/portage/package.unmask/100-my.package.unmask</code>

Before you unmask anything of ours, look in <code>/etc/portage/package.mask/00-*.package.mask</code> why we masked it, there is usually a comment. In user mode, an unmasked or keyworded version that is not on our binhost can't be installed.

== Per package environment ==

<code>/etc/portage/package.env/</code> together with <code>/etc/portage/env/</code> lets you compile some packages with different settings (CFLAGS, FEATURES, MAKEOPTS, ...). We use it for a few packages already, see <code>/etc/portage/package.env/00-argent.package.env</code>. The Gentoo documentation for it is [https://wiki.gentoo.org/wiki//etc/portage/package.env here].

Your own, for example to compile a big package with fewer jobs:

<code>echo 'MAKEOPTS="-j2"' > /etc/portage/env/100-my-lowjobs.conf</code>

<code>echo "www-client/chromium 100-my-lowjobs.conf" >> /etc/portage/package.env/100-my.package.env</code>

This only matters when a package gets compiled, so devmode or srcmode.

== Sets ==

Argent ships its own package sets in <code>/etc/portage/sets/</code>: <code>@basesystem</code>, <code>@plasma-full</code>, <code>@plasma-tools</code>, <code>@multimedia</code>, <code>@tools</code> and so on. To see what is in one:

<code>cat /etc/portage/sets/basesystem</code>

To install one:

<code>epkg install @multimedia</code>

You can make your own set, it's a text file with one package per line. '''Careful with the name''': our set names have no dot, but yours must have one, otherwise <code>epkg update</code> deletes it:

<code>/etc/portage/sets/my.tools</code>

and then:

<code>epkg install @my.tools</code>

== The world file ==

<code>/var/lib/portage/world</code> is the list of packages you asked for. Everything else on your system is there because something in that list needs it.

* <code>epkg install</code> adds to it
* <code>epkg oneshot</code> and <code>epkg recompile</code> don't
* <code>epkg remove</code> takes out of it
* <code>epkg clean</code> removes everything that nothing in it needs anymore

To take a package out of it without removing the package itself (it goes away at the next <code>epkg clean</code>, if nothing else needs it):

<code>emerge --deselect <package></code>