Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds
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
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
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. > > > mailto:wlt...@o-sinc.com>> 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
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. > > mailto:wlt...@o-sinc.com>> 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
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
On 12/07/17 17:07, Gordon Pettey wrote: > On Wed, Jul 12, 2017 at 10:14 AM, William L. Thomson Jr. > mailto:wlt...@o-sinc.com>> wrote: > > On Thu, 13 Jul 2017 01:03:00 +1000 > Sam Jorna mailto:wra...@gentoo.org>> 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
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
On Thu, 13 Jul 2017 01:03:00 +1000 Sam Jorna wrote: > 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. It is similar to the warnings that exist now. To my knowledge, other than generic messages that are always there, and a user is likely to ignore as noise. Nothing to my knowledge will tell you that someone was not removed because it a was a dependency. Neither -c, nor -C does this. I get -C maybe unware, but -c is not. Even when adding -v to -c, it does not explicitly say the package was not removed because another needs it. That is assumed, and IMHO the user is left wanting as previously stated. > $ 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. > 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. I was proposing to provided further information to the user unique to that situation. Not removing because it is a dependency. -- William L. Thomson Jr. pgpPKYiZTWMxH.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds
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
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
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
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
On 12/07/17 15:36, William L. Thomson Jr. wrote: > 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. 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. > 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. >> 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? 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. >> 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. >> 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 > So the idea is to duplicate the functionality of '--depclean ' without actually checking to see if the package is a dependency, 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? -- 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
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
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
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
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
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
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
On Wed, 12 Jul 2017 00:00:24 -0400 "William L. Thomson Jr." wrote: > 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. The whole purpose of this topic. I wanted to use sets in my custom profiles and I could not I did not want to mess with meta ebuilds. I make enough ebulids as it is. Maybe more than any other single.[1] Think about that? Why would I be messing with profiles, if I am dealing with things one off? I only am invoking emerge on things I am actively developing or packaging. The rest is handled via other means. I do appreciate all the lessons and instructions. Not sure when people will learn to stop assuming things about others. Many married couples barely know their spouse. You have no chance online 1. https://github.com/Obsidian-StudiosInc/os-xtoo/ -- William L. Thomson Jr. pgpD3cVAF1Mt8.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds
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
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
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
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
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
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
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
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
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
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