On 2026-02-10, Alan Mackenzie wrote:
> Hello, Eli.
>
> On Mon, Feb 09, 2026 at 15:50:27 -0500, Eli Schwartz wrote:
>> On 2/9/26 12:04 PM, Alan Mackenzie wrote:
>
>> The package is installed because there is a file /usr/bin/php8.2
>> installed, and it is *the package* that installed it.
>
> I think it more the other way around. The directory exists in /usr/bin
> because the package is installed. It's just the meaning of "package
> installed" which I was trying to clarify.
>
>> ebuilds are NOT packages. They are bash scripts describing how to build
>> a package. Removing an ebuild from /usr/portage (2017) or /var/db/repos
>> (new canonical place) removes the bash script describing how to build
>> it. It does NOT remove /usr/bin/php8.2, that would be insane...
>
> I spent quite a bit of yesterday evening trying to find where this is
> explained in the docs. I haven't found anything clearly outlining the
> difference between ebuilds and packages, and the fact that the latter
> can continue to exist after the deletion of the former.
>
>> ... hence the package is installed, still.
>
> Yes.
>
>> /var/db/pkg is not "orphaned" nor is it a bug, it is the database of
>> installed files etc.
>
> The database of installed packages. Yes, got that now, thanks.
With a package manager, you have to have, somehow
1) The files on the system/filesystem which the package manager is
managing installations for
2) The repository/list/tree/database of installable packages (this is
what used to be in /usr/portage, the part which gets synced, and of
course several package managers support multiple repositories)
3) Some sort of tracking system so that the package manager can keep
track of what is installed, and can e.g. remove files to uninstall a
package. And also keep track of dependencies so that these can be
kept installed and updated. On Gentoo, this includes /var/db/pkg/ and
/var/lib/portage/world.
>> >> If you don't need this package and emerge -pvc shows nothing requiring
>> >> it, maybe you can just remove it (e.g. with emerge -avc)?
>
>> > I can't use emerge, because there's no ebuild for php-8.2.28-r1. It's
>> > looking as though I'll have to delete the directory under /var/db/... by
>> > hand, together with all the associated files throughout the system.
>
>> > Or, maybe if I let # USE='...' emerge =dev-lang/php-8.2.30 go ahead, it
>> > will clear out the old directory in /var/db/... Maybe.
>
>> > Is this worth a bug report, or have I misunderstood something else?
>
>
>> I already told you the same thing, though. My previous email:
>
> I wasn't sure whether or not you were giving me a solution or a
> workaround. At that stage I hadn't yet understood what my problem was.
> But I've now removed php-8.2.n entirely.
>
>> >> I've cleaned up my orphan packages (most of them), but don't trust
>> >> --depclean to do so. It still wants to remove some packages I need and
>> >> want to keep.
>
>> > It will, by definition, remove packages not in world (emerge foobar
>> > without --oneshot).
>
>> > So, one must conclude you, for whatever reason, wished to oneshot these
>> > packages and not add them to world.
>
> No, that's not the case. The particular package is daemontools, and I
> most certainly didn't give it the -1 when installing. Why would I? It
> got caught up in a portage mixup with the OpenRC's daemon handler. This
> is now fixed, but somehow daemontools hasn't made it into my @world.
>
> This is just one isolated instance, but there might be more isolated
> instances by which --depclean could render my system unbootable. So,
> like it itself directs, I always check very carefully the suggestions it
> makes for removal.
>
>> > This is your choice and your right, but it renders depclean ineffective.
>
> As I say I don't trust --depclean. I check its suggestions carefully,
> then delete (some of) them by hand. For example, I don't let it remove
> older kernel packages, or older gcc versions.
Do note that these are two different uses of --depclean, to remove
unneeded packages from the system versus to remove a specific package.
>From the online manual:
«--depclean, -c
[...]
Depclean serves as a dependency aware version of --unmerge. When
given one or more atoms, it will unmerge matched packages that
have no reverse dependencies. Use --depclean together with
--verbose to show reverse dependencies.»
(Although I kind of feel like ". When" should continue with a comma
instead?)
--
Nuno Silva
