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

[Aaron W. Swenson]

On 2017-07-15 01:34, Raymond Jennings wrote:
> On Wed, Jul 12, 2017 at 9:07 AM, Gordon Pettey  wrote:
> 
> > On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr. <
> > wlt...@o-sinc.com> wrote:
> >
> >> On Thu, 13 Jul 2017 01:03:00 +1000
> >> Sam Jorna  wrote:
> >>
> >> > $ emerge -C apg
> >> >  * This action can remove important packages! In order to be safer,
> >> > use
> >> >  * `emerge -pv --depclean ` to check for reverse dependencies
> >> > before
> >> >  * removing packages.
> >>
> >> That is my point. That message is always there. The chance that it is
> >> ignored is very high.
> >>
> >>
> > Stop signs on the road are also always there. If you get arrested for
> > ignoring it, it is not because the stop signs are always there, it is
> > because you ignored it. Don't ignore the warning.
> >
> 
> Just to be pedantic:
> 
> You can usually only be arrested for felonies and misdemeanors.
> 
> Ignoring a stop sign and most traffic related offenses in general are
> infractions or violations.  For those, you just get cited with a nasty
> ticket and an annoying fine.

Well, that depends. One stop sign and no other vehicles involved? Just a
ticket.

Run a stop sign and while swerving around the road risking the lives of
others because you can’t be bother to pay attention to the signs? That’s
an arrest.


signature.asc
Description: Digital signature

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

[Raymond Jennings]

On Wed, Jul 12, 2017 at 9:07 AM, Gordon Pettey  wrote:

> On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr. <
> wlt...@o-sinc.com> wrote:
>
>> On Thu, 13 Jul 2017 01:03:00 +1000
>> Sam Jorna  wrote:
>>
>> > $ emerge -C apg
>> >  * This action can remove important packages! In order to be safer,
>> > use
>> >  * `emerge -pv --depclean ` to check for reverse dependencies
>> > before
>> >  * removing packages.
>>
>> That is my point. That message is always there. The chance that it is
>> ignored is very high.
>>
>>
> Stop signs on the road are also always there. If you get arrested for
> ignoring it, it is not because the stop signs are always there, it is
> because you ignored it. Don't ignore the warning.
>

Just to be pedantic:

You can usually only be arrested for felonies and misdemeanors.

Ignoring a stop sign and most traffic related offenses in general are
infractions or violations.  For those, you just get cited with a nasty
ticket and an annoying fine.

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

[Pacho Ramos]

El mié, 12-07-2017 a las 12:38 -0400, William L. Thomson Jr. escribió:
> On Wed, 12 Jul 2017 17:23:43 +0100
> "M. J. Everitt"  wrote:
> 
> > On 12/07/17 17:07, Gordon Pettey wrote:
> > > On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr.
> > > > wrote:
> > > That is my point. That message is always there. The chance that
> > > it is ignored is very high.
> > > 
> > > 
> > > Stop signs on the road are also always there. If you get arrested
> > > for ignoring it, it is not because the stop signs are always there,
> > > it is because you ignored it. Don't ignore the warning.  
> > 
> > Can't help but think of "special snowflake" here 
> 
> More like saying something to me because it is me, despite that I
> literally pointed that out to others. In a situation that actually
> matters. This should be said to others not me. But everyone feels ilke
> they need to comment something to me, that applies to another, but not
> said to that other.
> 
> Again
> https://archives.gentoo.org/gentoo-dev/message/a0470e1cc2c05afc1e30c09f3f239b2
> 4
> 
> Really funny stuff
> 
> --

After re-reading all the thread again:
https://lists.gt.net/gentoo/dev/327773/?page=1;mh=-1;

I think there is no point in continuing replying forever to this thread as I
think all the technical issues has now being, at least, clarified and forwarded
to the right people. As I have understood most of them belong to Portage team
and now that the bug reports with the concrete suggestions were filled, they
will be able to deal with them (either working on implementing the desired
changes or either declining to do that if they have other opinions based on the
way portage is supposed to be used by us). 

Then, can we please switch to different and more productive things to do? :)

Thanks a lot!

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

[William L. Thomson Jr.]

On Wed, 12 Jul 2017 17:23:43 +0100
"M. J. Everitt"  wrote:

> On 12/07/17 17:07, Gordon Pettey wrote:
> > On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr.
> > > wrote:

> > That is my point. That message is always there. The chance that
> > it is ignored is very high.
> >
> >
> > Stop signs on the road are also always there. If you get arrested
> > for ignoring it, it is not because the stop signs are always there,
> > it is because you ignored it. Don't ignore the warning.  
> Can't help but think of "special snowflake" here 

More like saying something to me because it is me, despite that I
literally pointed that out to others. In a situation that actually
matters. This should be said to others not me. But everyone feels ilke
they need to comment something to me, that applies to another, but not
said to that other.

Again
https://archives.gentoo.org/gentoo-dev/message/a0470e1cc2c05afc1e30c09f3f239b24

Really funny stuff

--
-- 
William L. Thomson Jr.


pgpdqJA9f1X5O.pgp
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Wed, 12 Jul 2017 11:07:00 -0500
Gordon Pettey  wrote:

> On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr.
>  wrote:
>
> > That is my point. That message is always there. The chance that it
> > is ignored is very high.
> >
> >
> Stop signs on the road are also always there. If you get arrested for
> ignoring it, it is not because the stop signs are always there, it is
> because you ignored it. Don't ignore the warning.

And again another commenting who did not follow the thread. Talking to
the wrong person, replying at the wrong point.

Who is ignoring warnings? Me or others?
https://archives.gentoo.org/gentoo-dev/message/a0470e1cc2c05afc1e30c09f3f239b24

Guess you missed where I was pointing out important warnings others
were ignoring. Much more so than the generic output that is always
present with emerge -C/--unmerge.

Also in what country do you get arrested for running a stop sign?

-- 
William L. Thomson Jr.


pgpL9CyAAquYA.pgp
Description: OpenPGP digital signature

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

[M. J. Everitt]

On 12/07/17 17:07, Gordon Pettey wrote:
> On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr.
> > wrote:
>
> On Thu, 13 Jul 2017 01:03:00 +1000
> Sam Jorna > wrote:
>
> > $ emerge -C apg
> >  * This action can remove important packages! In order to be safer,
> > use
> >  * `emerge -pv --depclean ` to check for reverse dependencies
> > before
> >  * removing packages.
>
> That is my point. That message is always there. The chance that it is
> ignored is very high.
>
>
> Stop signs on the road are also always there. If you get arrested for
> ignoring it, it is not because the stop signs are always there, it is
> because you ignored it. Don't ignore the warning.
Can't help but think of "special snowflake" here 

*cue flamewar...*


signature.asc
Description: OpenPGP digital signature

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

[Gordon Pettey]

On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr. 
wrote:

> On Thu, 13 Jul 2017 01:03:00 +1000
> Sam Jorna  wrote:
>
> > $ emerge -C apg
> >  * This action can remove important packages! In order to be safer,
> > use
> >  * `emerge -pv --depclean ` to check for reverse dependencies
> > before
> >  * removing packages.
>
> That is my point. That message is always there. The chance that it is
> ignored is very high.
>
>
Stop signs on the road are also always there. If you get arrested for
ignoring it, it is not because the stop signs are always there, it is
because you ignored it. Don't ignore the warning.

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

[Sam Jorna]

On 13/07/17 00:19, William L. Thomson Jr. wrote:
> It is YOUR comments that are funny, and going in a circular argument
> just to be argumentative and bringing nothing useful to the discussion.
> Which should be over now that bugs are filed

I'm not trying to be argumentative or antagonistic, I'm trying to
understand how your replacement warning differs from what's already
available and adds value.

>> '--depclean foo' is the user removing something they /are/ aware of
>> *if it's not a dependency*.
> 
> That does not work the same. It will not remove a package from world.

$ grep apg /var/lib/portage/world
app-admin/apg

$ emerge -C apg
 * This action can remove important packages! In order to be safer, use
 * `emerge -pv --depclean ` to check for reverse dependencies before
 * removing packages.

>>> Unmerging in: 5 4 3 2 1
>>> Unmerging (1 of 1) app-admin/apg-2.3.0b-r5...

...

$ grep apg /var/lib/portage/world
app-admin/apg

$ emerge -c apg

Calculating dependencies... done!
>>> Calculating removal order...

>>> Unmerging in: 5 4 3 2 1
>>> Unmerging (1 of 1) app-admin/apg-2.3.0b-r5...

> Clearly you are having a hard time grasping this very simple concept.
> I am done, reply if you like, but this thread is serious noise now...

Clearly, hence why I was trying to understand what difference your
proposal offered. But since we're moving on to serious things now, I
guess I /am/ done with this thread.

-- 
Sam Jorna (wraeth) 
GnuPG Key: D6180C26



signature.asc
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Wed, 12 Jul 2017 16:40:11 +1000
"Sam Jorna (wraeth)"  wrote:

> If my concern in removing a package was whether it was a dependency,
> it would make more sense to use --depclean in the first place. If I'm
> using --unmerge, it's because I want the package unmerged regardless.

But you can't remember what you installed or ate for dinner. What if you
are removing something you need?

> > Didn't you just say something about meaningful output vs noise?
> > That is always outputted and ends up becoming what you are saying.
> > Funny!  
> >
> And your suggesting adding more noise to it... Funny, I know.

No a warning that mentions the package not being removed is not noise.
It is useful output, like the warnings that exist for other things now.

I guess in your opinion this warning is noise to you.

!!! 'sys-devel/gcc' is part of your system profile.
!!! Unmerging it may be damaging to your system.

It is YOUR comments that are funny, and going in a circular argument
just to be argumentative and bringing nothing useful to the discussion.
Which should be over now that bugs are filed

> > Depclean the user is cleaning things they are not aware of. Unmerge
> > the user is removing something directly. They may think they do not
> > need it.  
> 
> No.
> 
> '--depclean' is the user removing things they are not aware of.

You literally just re-typed what I did above replacing cleaning with
removing. Are you paying any attention?

> '--depclean foo' is the user removing something they /are/ aware of
> *if it's not a dependency*.

That does not work the same. It will not remove a package from world.

> '--unmerge foo' is the user explicitly removing something regardless
> of whether it's a dependency.

BUT they are warned now for things that are in a profile or set. Thus
they should be warned if a dependency. Its simply, but clearly your
having a hard time grasping.

> Therefore, '--depclean foo' can be seen as a safe '--unmerge foo'
> which, from what I understand, is what you're aiming for.

No, as they are not the same. You cannot remember what you ate. Please
stop trying to assume what I am after. Clearly we are very different. I
know what I ate last night...

> That's what the current warning to --unmerge says - removing packages
> can break things, so please make sure this isn't a dependency and you
> really want to remove this.

They do not say anything about dependencies. It says the same message
for everything. In some cases for system and set packages you get a
warning.

> How does replacing one warning with another warning that may or may
> not be meaningful ("maybe it's a dep, maybe it isn't" as opposed to
> "this can be dangerous, please make sure you know what you're doing")
> make it any better?

It is not replacing a warning. It is adding the same warning that exist
in other situations in one it does not exists now, removing
dependencies.

Clearly you are having a hard time grasping this very simple concept.
I am done, reply if you like, but this thread is serious noise now...

-- 
William L. Thomson Jr.


pgpI3YxGNphyg.pgp
Description: OpenPGP digital signature

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

[Sam Jorna (wraeth)]

On 12/07/17 16:06, William L. Thomson Jr. wrote:
> On Wed, 12 Jul 2017 15:49:14 +1000
> "Sam Jorna (wraeth)"  wrote:
>>
>> I have trouble remembering what I ate for dinner last night, let alone
>> what I may or may not have merged a week, month or year ago, or what
>> options I used when merging it.
> 
> And if you used --oneshot, it is also saying you are not maintaining
> your system or ever running --depclean. Since anything you installed
> via --oneshot would be removed with --depclean.

If my concern in removing a package was whether it was a dependency, it
would make more sense to use --depclean in the first place. If I'm using
--unmerge, it's because I want the package unmerged regardless.

>>> What harm does a warning do?  
>>
>> Depends on the user, which can't really be avoided, but means that
>> warnings should be clear and meaningful, otherwise they become
>> background noise.
> 
> The example in the bug is as clear is it can get.
> 
> !!! 'sys-devel/gcc' is a dependency of another package on your system
> or
> !!! 'sys-devel/gcc' is a package not found in system profile or world
> or
> !!! 'sys-devel/gcc' may not have been installed by you
> or
> some other message
> 
>> Such as:
>>
>> emerge --unmerge dev-python/keyring
>>  * This action can remove important packages! In order to be safer,
>> use
>>  * `emerge -pv --depclean ` to check for reverse dependencies
>> before
>>  * removing packages.
> 
> Didn't you just say something about meaningful output vs noise? That is
> always outputted and ends up becoming what you are saying. Funny!

And your suggesting adding more noise to it... Funny, I know.

 or may have been installed as an orphan but is now a
 dependency.   
>>>
>>> Now being a dependency the warning would be valid.  
>>
>> "Sometimes being accurate" is not the most noble of goals.
> 
> What?
> 
>> So the idea is to duplicate the functionality of '--depclean
>> 
> 
> NO!!!
> 
> emerge --depclean gcc 
> 
> is not the same as 
> 
> emerge --umerge gcc
> 
> Depclean the user is cleaning things they are not aware of. Unmerge the
> user is removing something directly. They may think they do not need it.

No.

'--depclean' is the user removing things they are not aware of.

'--depclean foo' is the user removing something they /are/ aware of *if
it's not a dependency*.

'--unmerge foo' is the user explicitly removing something regardless of
whether it's a dependency.

Therefore, '--depclean foo' can be seen as a safe '--unmerge foo' which,
from what I understand, is what you're aiming for.

>> ' without actually checking to see if the package is a
>> dependency,
> 
> Word it how ever. If the user did not install, they should be warned on
> removal of a package they did not install.

That's what the current warning to --unmerge says - removing packages
can break things, so please make sure this isn't a dependency and you
really want to remove this.

>> only whether it is listed in a set; or to check if it's a
>> dependency of /something/ and, if so, redirect the user to the
>> command they should be using anyway?
> 
> You mean like emerge --unmerge does already that you pointed out
> above. After mentioning useful messages vs noise.  Again funny!

How does replacing one warning with another warning that may or may not
be meaningful ("maybe it's a dep, maybe it isn't" as opposed to "this
can be dangerous, please make sure you know what you're doing") make it
any better?

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Wed, 12 Jul 2017 15:49:14 +1000
"Sam Jorna (wraeth)"  wrote:
>
> I have trouble remembering what I ate for dinner last night, let alone
> what I may or may not have merged a week, month or year ago, or what
> options I used when merging it.

And if you used --oneshot, it is also saying you are not maintaining
your system or ever running --depclean. Since anything you installed
via --oneshot would be removed with --depclean.

> > What harm does a warning do?  
> 
> Depends on the user, which can't really be avoided, but means that
> warnings should be clear and meaningful, otherwise they become
> background noise.

The example in the bug is as clear is it can get.

!!! 'sys-devel/gcc' is a dependency of another package on your system
or
!!! 'sys-devel/gcc' is a package not found in system profile or world
or
!!! 'sys-devel/gcc' may not have been installed by you
or
some other message

> Such as:
> 
> emerge --unmerge dev-python/keyring
>  * This action can remove important packages! In order to be safer,
> use
>  * `emerge -pv --depclean ` to check for reverse dependencies
> before
>  * removing packages.

Didn't you just say something about meaningful output vs noise? That is
always outputted and ends up becoming what you are saying. Funny!
 
> >> or may have been installed as an orphan but is now a
> >> dependency.   
> > 
> > Now being a dependency the warning would be valid.  
> 
> "Sometimes being accurate" is not the most noble of goals.

What?

> So the idea is to duplicate the functionality of '--depclean
> 

NO!!!

emerge --depclean gcc 

is not the same as 

emerge --umerge gcc

Depclean the user is cleaning things they are not aware of. Unmerge the
user is removing something directly. They may think they do not need it.

>' without actually checking to see if the package is a
> dependency,

Word it how ever. If the user did not install, they should be warned on
removal of a package they did not install.

> only whether it is listed in a set; or to check if it's a
> dependency of /something/ and, if so, redirect the user to the
> command they should be using anyway?

You mean like emerge --unmerge does already that you pointed out
above. After mentioning useful messages vs noise.  Again funny!

-- 
William L. Thomson Jr.


pgpQjPL9OBJa_.pgp
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Wed, 12 Jul 2017 15:19:32 +1000
"Sam Jorna (wraeth)"  wrote:

> On 12/07/17 15:14, William L. Thomson Jr. wrote:
> > Is it in system?
> > Is it in a set?
> > Is it in world?
> > If no to all, its a dep, warn!  
> 
> All this says is whether the package was explicitly installed and
> recorded in world, or is a member of @system. The target package may
> or may not be a dependency, may or may not have been --oneshot'd.

Then when the user sees the warning they can discard knowing they
merged the package with --oneshot.

What harm does a warning do?

> It may have been installed as a dependency but the requiring package
> was removed,

Then the person failed to run --depclean and maintain their system.
Either way, did the person install the package directly?

If the package was not installed by the user. Should they not be warned
about removing something they did not install?

> or may have been installed as an orphan but is now a
> dependency. 

Now being a dependency the warning would be valid.

>Assuming that if it's not in a set it must be a dependency  is
>incorrect and misleading.

Again there are various ways. There cannot be that much overhead to
check if a single package depends on one being removed. If you cannot
use simpler methods as mentioned.

Clearly people have objections to warnings about packages users did not
install themselves

-- 
William L. Thomson Jr.


pgp9MrrKBm3bB.pgp
Description: OpenPGP digital signature

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

[Sam Jorna (wraeth)]

On 12/07/17 15:14, William L. Thomson Jr. wrote:
> Is it in system?
> Is it in a set?
> Is it in world?
> If no to all, its a dep, warn!

All this says is whether the package was explicitly installed and
recorded in world, or is a member of @system. The target package may or
may not be a dependency, may or may not have been --oneshot'd.

It may have been installed as a dependency but the requiring package was
removed, or may have been installed as an orphan but is now a
dependency. Assuming that if it's not in a set it must be a dependency
is incorrect and misleading.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Wed, 12 Jul 2017 15:00:30 +1000
"Sam Jorna (wraeth)"  wrote:
> 
> My point was that --unmerge is not intended to be dependency-aware.
> --depclean is. As far as I can tell, that is the point others have
> been trying to make as well, when pointing out the differences
> between -c and -C.

Sure but that is easily addressed.

How does emerge know a package is in system profile or a set?
Similar methods or others can be used to determine if a user installed
a package.

In a clean scenario, with a world file that ONLY contains stuff the
user merged directly. Then emerge could simply check that file, against
the stuff it already checks now.

Is it in system?
Is it in a set?
Is it in world?
If no to all, its a dep, warn!

It is really NOT complex, nor does it require complex depgraph or any
of the function of --depclean/-c.

Thus I say once again, mentioning anything to do with depclean is not
relevant and side tracks the discussion. There is no need. If you did
want to actually see if any deps existed. All you need is to see if
there is 1 installed package that needs the one a user is trying to
install. No need for a complete depgrah etc.

There are several ways to go about this that are not complex.

-- 
William L. Thomson Jr.


pgp_HMN_6hxYC.pgp
Description: OpenPGP digital signature

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

[Sam Jorna (wraeth)]

On 12/07/17 14:43, William L. Thomson Jr. wrote:
>>> It is not the same as -C, which is remove a package directly.
>>>
>>>  --unmerge (-C)  
>> Correct, --unmerge will remove a package without considering
>> dependencies (give or take a few special cases). It is usually (or, at
>> least, should generally be) reserved for those taking a hammer to a
>> problem or with a particular desire to recover a broken system.
>>
>> Again, it's doing exactly what it's supposed to - removing a package
>> you've told it to remove (unless it's one of the few
>> almost-always-critical packages).
> Yes and if you see bug. All I am saying is adding warnings when someone
> goes to remove a dependency. Since a dependency IS a critical package :)
> 
> Add warning message when -C/--unmerge a dependency like system,
> profile, and set files.
> https://bugs.gentoo.org/show_bug.cgi?id=624630

My point was that --unmerge is not intended to be dependency-aware.
--depclean is. As far as I can tell, that is the point others have been
trying to make as well, when pointing out the differences between -c and -C.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Wed, 12 Jul 2017 14:17:30 +1000
"Sam Jorna (wraeth)"  wrote:
>
> --depclean is doing exactly what it is supposed to. If called with no

Problem is I was talking about removing packages directly. It served no
purpose in this discussion.

Since I use --depclean, not -c. I was assuming -c was unmerge like -C,
but it is not. Others brought that up and sidetracked things. I just
did not catch and mistakenly went down that wormhole.

> 
> > It is not the same as -C, which is remove a package directly.
> > 
> >  --unmerge (-C)  
> 
> Correct, --unmerge will remove a package without considering
> dependencies (give or take a few special cases). It is usually (or, at
> least, should generally be) reserved for those taking a hammer to a
> problem or with a particular desire to recover a broken system.
> 
> Again, it's doing exactly what it's supposed to - removing a package
> you've told it to remove (unless it's one of the few
> almost-always-critical packages).

Yes and if you see bug. All I am saying is adding warnings when someone
goes to remove a dependency. Since a dependency IS a critical package :)

Add warning message when -C/--unmerge a dependency like system,
profile, and set files.
https://bugs.gentoo.org/show_bug.cgi?id=624630


-- 
William L. Thomson Jr.


pgp5mukQUK6hy.pgp
Description: OpenPGP digital signature

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

[Sam Jorna (wraeth)]

On 12/07/17 10:05, William L. Thomson Jr. wrote:
> I should have caught that sooner. -c does not remove a package, it just
> removes its deps.
> 
> -c == --depclean.

--depclean is doing exactly what it is supposed to. If called with no
arguments, it searches for any unneeded dependencies and removes them,
however if called with a package as an argument, it will remove that
package *if it is not a dependency of another package*. Reporting
"nothing to remove" is precisely what it's supposed to do, and using
--verbose will tell you what is depending on the package.

To be clear, running '--depclean foo' does not remove dependencies of
foo, it removes foo provided it is not a dependency. It can be seen as a
dependency-aware (and thus, generally safe) --unmerge.

Making --depclean _always_ give you more information should just be a
case of adding --verbose to EMERGE_DEFAULT_OPTS.

> It is not the same as -C, which is remove a package directly.
> 
>  --unmerge (-C)

Correct, --unmerge will remove a package without considering
dependencies (give or take a few special cases). It is usually (or, at
least, should generally be) reserved for those taking a hammer to a
problem or with a particular desire to recover a broken system.

Again, it's doing exactly what it's supposed to - removing a package
you've told it to remove (unless it's one of the few
almost-always-critical packages).

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Wed, 12 Jul 2017 04:43:41 +0100
"M. J. Everitt"  wrote:
> 
> Of course, you can do what Poettering did, and write your own solution
> .. or fork portage to do things the way -you- want .. but don't
> reinvent the wheel for the rest of us .. that's what Choice and
> Gentoo is all about ...


Its not for me. It is not re-inventing the wheel. It is safe guard
stuff that benefits all. See bugs.

-- 
William L. Thomson Jr.


pgp9uZ61eHSJZ.pgp
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Tue, 11 Jul 2017 23:22:12 -0400
"Walter Dnes"  wrote:
> 
>   Step back for a minute, and relax.  There is a reason you're getting
> blowback.  You're asking for changes that would affect everybody else.
> This is similar in principle to what Lennart Poettering did, and
> you're getting the same reaction he got.  I understand that *YOU*
> want changes to how Portage works on *YOUR* machine.  No problem.  Set
> EMERGE_DEFAULT_OPTS in make.conf.  If you want excruciating detail on
> --depclean then check the small script I posted elsewhere in this
> thread.  Portage has many customization options; use them.

I am relaxed, and if you understand what I am proposing. It will only
help everyone. There is no harm in adding warmings that provide
additional information.

Preventing stuff from being added to world is moot, as that stuff comes
from something else, profile, set, etc. It being added to world serves
no purpose, Just can cause issues down the road. Stuff remaining that
may have not been wanted, but ended up in world so persists and gets
updated, etc.

What purpose does system profile packages saved in world serve?

These changes are NOT for me... I can edit and code myself. This is for
others per this discussion. Others brought up sets accidentally
removing system stuff, etc. Thus these ideas came up as ways to prevent
others from shooting themselves in the foot.

The blowback is mostly because its me, and people are misunderstanding
things. Like the mention of -c/--depclean. Which does not have the same
function as -C/--unmerge. That sidetracked things and added nothing.

>   If you can't be bothered to use available customization options to
> set up your machine to your liking, but ask for a change of defaults
> that also affects everybody else, don't be surprised at the negative
> reaction. You would've gotten a much better reception, if you had
> gone to the gentoo-user list and asked "How do I tweak Portage to do
> this, that, and the other".

How many times do I have to say I use -1, and others like -O.  People
do not pay attention...

Again I do much of this via ansible and profiles. I am not even using a
world file, or sets even. I did use sets before my custom profiles. Did
I always use -1 for the past over a decade no? Should all users have to
in order to prevent needless stuff from being recorded in world.

Please do not assume what I am or am not doing and problems I am not
having. This is stuff for others. I am seeing problems that OTHERS can
run into per the discussion on sets. From things OTHERS mentioned as
issues with using sets.

Bugs are filed.

-- 
William L. Thomson Jr.


pgp9XVKcFMdK4.pgp
Description: OpenPGP digital signature

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

[M. J. Everitt]

On 12/07/17 04:22, Walter Dnes wrote:
>
>   Step back for a minute, and relax.  There is a reason you're getting
> blowback.  You're asking for changes that would affect everybody else.
> This is similar in principle to what Lennart Poettering did, and you're
> getting the same reaction he got.  I understand that *YOU* want changes
> to how Portage works on *YOUR* machine.  No problem.  Set
> EMERGE_DEFAULT_OPTS in make.conf.  If you want excruciating detail on
> --depclean then check the small script I posted elsewhere in this
> thread.  Portage has many customization options; use them.
>
>   If you can't be bothered to use available customization options to set
> up your machine to your liking, but ask for a change of defaults that
> also affects everybody else, don't be surprised at the negative reaction.
> You would've gotten a much better reception, if you had gone to the
> gentoo-user list and asked "How do I tweak Portage to do this, that, and
> the other".
>
+1

Of course, you can do what Poettering did, and write your own solution
.. or fork portage to do things the way -you- want .. but don't reinvent
the wheel for the rest of us .. that's what Choice and Gentoo is all
about ...



signature.asc
Description: OpenPGP digital signature

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

[Walter Dnes]

On Tue, Jul 11, 2017 at 04:57:21PM -0400, William L. Thomson Jr. wrote
> On Tue, 11 Jul 2017 13:27:57 -0700
> Daniel Campbell  wrote:
> 
> > 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.

  Step back for a minute, and relax.  There is a reason you're getting
blowback.  You're asking for changes that would affect everybody else.
This is similar in principle to what Lennart Poettering did, and you're
getting the same reaction he got.  I understand that *YOU* want changes
to how Portage works on *YOUR* machine.  No problem.  Set
EMERGE_DEFAULT_OPTS in make.conf.  If you want excruciating detail on
--depclean then check the small script I posted elsewhere in this
thread.  Portage has many customization options; use them.

  If you can't be bothered to use available customization options to set
up your machine to your liking, but ask for a change of defaults that
also affects everybody else, don't be surprised at the negative reaction.
You would've gotten a much better reception, if you had gone to the
gentoo-user list and asked "How do I tweak Portage to do this, that, and
the other".

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

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


pgpusktgEpxqE.pgp
Description: OpenPGP digital signature

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



signature.asc
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Tue, 11 Jul 2017 13:27:57 -0700
Daniel Campbell  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!!!

-- 
William L. Thomson Jr.


pgpAbQgpYXXiY.pgp
Description: OpenPGP digital signature

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

[Daniel Campbell]

On 07/11/2017 01:27 PM, Daniel Campbell wrote:
> On 07/10/2017 04:37 PM, William L. Thomson Jr. wrote:
>> On Mon, 10 Jul 2017 19:22:47 -0400
>> "William L. Thomson Jr."  wrote:
>>>
>>> That part does not require it to resolve deps. Just check world file,
>>> assuming its correct. Though could be thrown off if say gcc, or
>>> another was in the world file. I think the profile or set would catch
>>> that as it does now and generate a warning, regardless.
>>
>> Speaking of gcc in the world file. I think portage should STOP adding
>> packages that are in the profile or a dep to world. If you merge a
>> package as part of a set, I am pretty sure it does not get recorded to
>> world, need to confirm, could be wrong.
>>
>> 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.
>>
>> I will file a bug on that as well.
>>
> Whether Portage adds a package to a set or world file is dependent on
> how you invoke emerge. Some people (like me) include sets as part of
> their world, via /var/lib/portage/world_sets . At that point, sets added
> to that file are basically treated as the world package list.
> 
> If gcc or other @system packages end up in your world, it's not
> 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. I added it to my default
> emerge options in make.conf for exactly that reason (clean world);
> 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 you decide you want to add a package to world without re-merging it,
> -n (--noreplace) will do the job.
> 
> I'm not sure if eix-test-obsolete (from app-portage/gentoolkit) will
> catch a @system atom inside a set/world file, but that's where I'd
> expect such a notification to come from. The tool can help clean up
> unneeded entries in /etc/portage files, and would be a good fit for this
> particular issue.
> 
> 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.
> 
> Hope this helps,
> 
> zlg
> 
Whoops.

s/gentoolkit/eix/

Sorry for the spam.

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



signature.asc
Description: OpenPGP digital signature

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

[Daniel Campbell]

On 07/10/2017 04:37 PM, William L. Thomson Jr. wrote:
> On Mon, 10 Jul 2017 19:22:47 -0400
> "William L. Thomson Jr."  wrote:
>>
>> That part does not require it to resolve deps. Just check world file,
>> assuming its correct. Though could be thrown off if say gcc, or
>> another was in the world file. I think the profile or set would catch
>> that as it does now and generate a warning, regardless.
> 
> Speaking of gcc in the world file. I think portage should STOP adding
> packages that are in the profile or a dep to world. If you merge a
> package as part of a set, I am pretty sure it does not get recorded to
> world, need to confirm, could be wrong.
> 
> 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.
> 
> I will file a bug on that as well.
> 
Whether Portage adds a package to a set or world file is dependent on
how you invoke emerge. Some people (like me) include sets as part of
their world, via /var/lib/portage/world_sets . At that point, sets added
to that file are basically treated as the world package list.

If gcc or other @system packages end up in your world, it's not
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. I added it to my default
emerge options in make.conf for exactly that reason (clean world);
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 you decide you want to add a package to world without re-merging it,
-n (--noreplace) will do the job.

I'm not sure if eix-test-obsolete (from app-portage/gentoolkit) will
catch a @system atom inside a set/world file, but that's where I'd
expect such a notification to come from. The tool can help clean up
unneeded entries in /etc/portage files, and would be a good fit for this
particular issue.

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.

Hope this helps,

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



signature.asc
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 19:22:47 -0400
"William L. Thomson Jr."  wrote:
>
> That part does not require it to resolve deps. Just check world file,
> assuming its correct. Though could be thrown off if say gcc, or
> another was in the world file. I think the profile or set would catch
> that as it does now and generate a warning, regardless.

Speaking of gcc in the world file. I think portage should STOP adding
packages that are in the profile or a dep to world. If you merge a
package as part of a set, I am pretty sure it does not get recorded to
world, need to confirm, could be wrong.

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.

I will file a bug on that as well.

-- 
William L. Thomson Jr.


pgppvJ2qYUHfP.pgp
Description: OpenPGP digital signature