This is more a failsafe feature, and also needed for another bug I will file and link to this one. If you emerge a package that is part of system, world, profile, a set, or is a dependency. That package is added to world. If you want to prevent this, you must use the -1/--oneshot option. That function is fine and should remain in general for things the user might merge but does not want recorded to world. It should be modified such that by default, even if the user say emerges gcc. gcc is NOT ever, in any case added to their world file. Not as long as it is part of a system, profile, system, world, profile, a set, or emerged as a dependency. Only if say gcc was not present, and was not in any of those, should it be added to world. I propose that the "system" be checked before recording a new package to world. This way only packages the user explicitly merges that are theirs end up in world. Dependencies, and packages brought in via other means, other than directly by the user. Should not be written to world. It serves no purpose. It just corrupts that file, and if the stuff in profiles, world, system, or a set changes. That stuff remains because it was added to world. Leaving it to the user to go clean up that file, and remove packages they did not install themselves. But they may at some point need to say emerge gcc, or some system, profile, world, set, or dependency directly. Which if they do, it should not be added to world. Like that is done now. Thank you for your consideration of this request!
By the way, the mention of a file that is part of world should be ignored. That was stupid. In any list of system, world, profile, a set, or is a dependency, just forget about world. Obvious world stuff is written to the world file.... Also system and profile are likely the same. Thus it is just system profile, set, or dependency should not be recorded to world. Sorry for confusing it with adding world....
(In reply to William L. Thomson Jr. from comment #0) > It should be modified such that by default, even if the user say emerges > gcc. gcc is NOT ever, in any case added to their world file. Not as long as > it is part of a system, profile, system, world, profile, a set, or emerged > as a dependency. Only if say gcc was not present, and was not in any of > those, should it be added to world. There are multiple valid cases for including sys-devel/gcc in the @world. Preserving old slots, for a start. Furthermore, if I am a programmer and I *need* gcc for my work (which goes beyond whatever Portage does), I don't see any reason not to request it explicitly instead of relying on Gentoo providing it by default. > Dependencies, and packages brought in via other means, other than directly > by the user. Should not be written to world. It serves no purpose. It just > corrupts that file, and if the stuff in profiles, world, system, or a set > changes. That stuff remains because it was added to world. Leaving it to the > user to go clean up that file, and remove packages they did not install > themselves. It is never this simple. How do you distinguish whether a package was brought as a dependency? What about multiple slots? Do you consider all slots of a package to be brought as a dependency or only the newest one? What about || deps? Do you consider all packages out of || to be brought as a dependency? Remember that no ordering applies to ||, so all choices are worth the same. Gentoo packages can not be clearly split into 'useful programs' and 'dependencies'. There are many packages that provide both tools the user may want, and libraries that other programs may want. Even in Debian where packages are split into tiny pieces the implicit dependency concept is now discouraged (see: aptitude). Even if we had packages clearly split, this still wouldn't be a clear decision. There is no reason why a package couldn't depend e.g. on || of a few web browsers for some reason, and this must not cause emerge to refuse to record a web browser of user's choice. And there is no reason why a user couldn't record a dependent library of his project in @world if he so desires. If you want apt-get, use Ubuntu. Do not request Gentoo to turn into Ubuntu.
(In reply to Michał Górny from comment #2) > > There are multiple valid cases for including sys-devel/gcc in the @world. > Preserving old slots, for a start. Furthermore, if I am a programmer and I > *need* gcc for my work (which goes beyond whatever Portage does), I don't > see any reason not to request it explicitly instead of relying on Gentoo > providing it by default. If someone needs a particular gcc, then it will have a slot added as part of its emerge. It would not just be sys-devel/gcc in world. In that case it should be removed, no warning. HOWEVER, in the situation you suggest. You WILL get a warning now saying gcc is in your profile. When you are removing one that is NOT in your profile. Which that does not make sense either. Since you are not removing the system gcc by the one you have for your development needs. If we are talking just sys-devel/gcc and they are running a profile that brings in sys-devel/gcc by default. Then there is no purpose to recording that in world. Aside from using having another gcc, I say again, what purpose does sys-devel/gcc have in world, when it is also in the system profile? There is no purpose! > It is never this simple. How do you distinguish whether a package was > brought as a dependency? What about multiple slots? Do you consider all > slots of a package to be brought as a dependency or only the newest one? > What about || deps? Do you consider all packages out of || to be brought as > a dependency? Remember that no ordering applies to ||, so all choices are > worth the same. Clearly you have no ideas on the matter, thus should just avoid. This was all brought up and discussed on list. Clearly I avoided your replies. You clearly cannot avoid interacting with me. Go read the discussion on list. I have given ideas to everything you ask. > Gentoo packages can not be clearly split into 'useful programs' and > 'dependencies'. There are many packages that provide both tools the user may > want, and libraries that other programs may want. Even in Debian where > packages are split into tiny pieces the implicit dependency concept is now > discouraged (see: aptitude). Yes they can, you just are not capable of coming up with ideas to make such happen. That sounds more like a personal limitation than anything technical. This is not rocket science.... This is very possible. If the user is installing libraries that stuff is added to world as normal. The user can still add their own stuff to world. This is simply about auto adding stuff that already exists else where. > If you want apt-get, use Ubuntu. Do not request Gentoo to turn into Ubuntu. I do not even know what your talking about. I have never used apt, outside of travis... I took my LPIC long ago on RPM not DEB... STOP assuming things!!! Comment has literally no relevance or purpose on this bug....
Firstly, please do not reopen bugs that have been closed by the assignee. If you disagree with my decision, feel free to comment but leave the decision on reopening to us (the Portage team). Secondly, please restrain from offensive comments and shouting. This does not help anyone.
(In reply to Michał Górny from comment #4) > Firstly, please do not reopen bugs that have been closed by the assignee. If > you disagree with my decision, feel free to comment but leave the decision > on reopening to us (the Portage team). > > Secondly, please restrain from offensive comments and shouting. This does > not help anyone. Stop commenting on things the person has specifically multiple times requested you stop. This is assigned to a team not a person. Let others comment. Please again refrain from commenting on anything I am involved with. It is very simple. If others want to close this, that is their choice after a discussion. If you do not want to be part of this, then stay out of it. Stop closing things you are personally not interested in and having your personal say as the final word.
(In reply to William L. Thomson Jr. from comment #5) > (In reply to Michał Górny from comment #4) > > Firstly, please do not reopen bugs that have been closed by the assignee. If > > you disagree with my decision, feel free to comment but leave the decision > > on reopening to us (the Portage team). > > > > Secondly, please restrain from offensive comments and shouting. This does > > not help anyone. > > Stop commenting on things the person has specifically multiple times > requested you stop. This is assigned to a team not a person. Let others > comment. Please again refrain from commenting on anything I am involved > with. It is very simple. > William, it is not that simple. The bug is assigned to the portage team, you have gotten the resolution of the issue (WONTFIX) from a member of the portage team. There does not seem to be consent, or a broader need to implement your feature request, so you can of course use a patched version downstream if the feature is needed by yourself. I'm resetting this to the portage team's outcome
I would feel this better having a single comment from Zac Medico, who I have met and is the main portage maintainer.... I guess Zac Medico does not count. Right? You all do more portage development than him? The team commits combined barely equal his... Re-opening once again till one of the top committers here comments.... https://github.com/gentoo/portage/graphs/contributors I know who I am looking to interact with and others are simply getting in the way needlessly. Nor adding anything of techinical value to a bug report. There are mailing lists for discussion. Discussion took place before bugs were opened. There is NO need for repeat discussion here. Either Zac or vapier need close this bug, maybe dol-sen. Or any of them commenting I will accept. Anyone else need avoid and go write more portage code...
