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

[Daniel Campbell]

On 07/11/2017 01:57 PM, William L. Thomson Jr. wrote:
> On Tue, 11 Jul 2017 13:27:57 -0700
> Daniel Campbell <zlg@g.o> wrote:
>
>> On 07/10/2017 04:37 PM, William L. Thomson Jr. wrote:
>>> On Mon, 10 Jul 2017 19:22:47 -0400
>>
>>> A rule for portage could be;
>>>
>>>  - If the package is not in world and already installed. Do not add
>>> the package to world. If you are re-emerging a package already
>>>    installed. You do not have to use the -1 option.
>>>
>>> I have polluted so many world files with system packages and/or
>>> dependencies I re-emerged directly without -1. Those IMHO should
>>> never have been recorded to that file. They were brought in by
>>> other things. Only things in my world should be packages merged
>>> directly, not from profile, set, or a dep.
>
>> Portage's fault. If you don't want a package added to a set or world,
>> you'll need to use the -1 (--oneshot) option.
>
> Did you even read above? I clearly state WITHOUT -1 option....
>
>> I added it to my default
>> emerge options in make.conf for exactly that reason (clean world);
>
> The point is people should not have to do such. Or remember to always
> use -1 when re-emerging a dep, system, world, or set package.
>
>> though, I have to be careful and make sure packages I care about are
>> in a set somewhere or --depclean will wipe'em out. In short, Portage
>> won't stop you from shooting yourself in the foot.
>
> If those package are in your world file portage will not remove on
> depclean.
>
>> If you decide you want to add a package to world without re-merging
>> it, -n (--noreplace) will do the job.
>
> Or you can add it to the world file, or your profile/packages
> in /etc/portage, etc. There are other places, one does not have to
> emerge every package then want in world. Just the same it should not
> add stuff just the same from system, world,  sets, or deps of any of
> those 3.
>
>> That said, having helpful messages is a good addition, but needs to be
>> done in a way that is unambiguous and gives the user a clear solution.
>
> So now it must be clear to the user? That is the entire point I am
> making. The output now is not clear... But in improving such now there
> is concern over something no one cares about now.... Funny stuff!!!
>

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 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).

-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.

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.

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. Sometimes that's good (resolving a blocker the hard
way), sometimes it's bad (removing gcc on a whim). Warnings won't stop a
user doing that, because --unmerge is already documented with the
caveat. There must be a certain point where we as developers have to say
"You're on your own," or there will be so many rails and training wheels
that it loses value for the more experienced users, or a bunch of bugs
filed over failing to heed documentation, i.e. PEBKAC. I think -C is a
great place to draw that line.

The best way to get the ball rolling is file a feature request against
Portage and see what 'upstream' has to say. In the meantime, maybe try
your hand at hacking it. I've found people are a lot more receptive to
suggestions when you've already attempted to provide it. Even if the
solution is crap, people seem willing to help those who have the
gumption to help themselves.

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.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6