Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Tue, 11 Jul 2017 14:32:27 -0700
Daniel Campbell <zlg@g.o> wrote:
>
> I understand where you're coming from, I just thought to give a few
> tips to make life a bit easier for you since it works out pretty well
> for myself. I think your idea has merit, just unsure of where the
> functionality goes, since I'm not a Portage developer.

I have been using the -1 option myself for some time. I have also moved
away from having anything in world file. I have my own profiles and
such. Just not committed to my public overlay yet.

This is mostly for others. I do what ever I need directly for myself if
it really becomes an issue for me. But I appreciate the thought!

> I think the hard part of implementing this will be detecting whether a
> command-line-given package is (a) in a set/profile/world and (b) part
> of a dependency tree (i.e. shouldn't be removed).

I do not think it will be that complex. It already does this now for
system, world, and set files. It must be looking at files already.
Having it look at say /var/lib/world is just another file/location.

> -c already traverses the dependency tree. This one message may mean
> iterating through the list of candidate packages and comparing them
> against a set/profile/world *per package*, unless the vdb/cache makes
> this lookup cheap in terms of cycles. The message would be helpful,
> though again, eix-test-obsolete might be the right tool to build that
> feature into. I'd be interested in following the bug discussion, if
> you've already filed it.

The looking at say world file is more an issue for -C than -c. -c knows
there are deps. Thus all it needs is an additional minimal message. It
already says to see deps use -v. It just does not say, why it took no
action. But actually now that I looked at -c, it is completely wrong.

I should have caught that sooner. -c does not remove a package, it just
removes its deps.

-c == --depclean.

It is not the same as -C, which is remove a package directly.

 --unmerge (-C)

Not even sure why anyone suggested -c. That explains why I use -C and
not -c, but I do use --depclean. This whole thread and topic really got
sidetracked big time with -c vs -C.

-c should never be mentioned. I was about to file a bug when I noticed
such.

emerge -c gcc, would never remove gcc, only run depclean
emerge -C will remove gcc

> If you're really interested in the message from -C, it could be done
> by checking the argument list for packages in sets or profiles. But
> it's going to incur similar overhead that -c has because it
> necessarily has to check some sort of list before producing the
> message.

Yes this is just about -C, and as stated previously. Other stuff
already hits files, this is not different really.

> I do not think this message belongs in -C output, however; -C is
> intentionally meant for operations where you don't care what happens
> to the dependency tree

Not true, as I have shown, -C will warn on removing system, world, and
set packages.

-C will NOT worn on dependencies, which it should. Using the world file
and others to know if a package is a dep or in one of those files.

> Please don't interpret this e-mail as aggressive or dismissive. I'm
> simply trying to offer explanation and guidance to help you make this
> happen. It's clear that you care about it, so I'm sure there's a way
> for this to go forward.

I do not, long as it is not insulting which it does not contain
anything of the sort. Though the discussion or mention of -c/--depclean
is really off topic. That confused and side tracked things.

-- 
William L. Thomson Jr.