It would be useful to be able to use package sets in profile packages. To do this safely may require logic that the sets can only contain package names and not other modifiers, use expansion, versions, etc. Also something would have to be done to support the set file not having * in front of each package name. Ideally for a profile/packages I would like to be able to add @my_set. Or *my_set for a package set to be included in that profile. Which I can then do emerge @my_set to rebuild those packages, etc. Per discussion on -dev https://archives.gentoo.org/gentoo-dev/message/c7788add677b15b4878e8b4a5a15a0c2 Thank you for your consideration of this feature request.
Can you clarify why you need to add a set to profile? Why not just create a set, say in /etc/portage/sets/rss and add it to /var/lib/portage/world_sets as @rss? It looks like you need some advanced functionality but you did not explain what exactly you try to achieve.
I am making custom profiles. I would like to use sets in my profiles. Why does the need matter to you? If someone wants to use sets in profile, they likely have a reason. Why does it need be known to others? Please stop trying to figure out what I am doing and just stick to the feature being requested. Thank you! https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/profiles https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/sets
Because I don't understand the semantic difference between a "set in world set" and a "set in profile". Both need to be added/switched-over explicitly and seem to do the same thing.
The profile contents are defined by the PMS. You'll most likely want to include a proper definition of set along with this feature in the next EAPI. (In reply to William L. Thomson Jr. from comment #2) > I am making custom profiles. I would like to use sets in my profiles. Why > does the need matter to you? If someone wants to use sets in profile, they > likely have a reason. Why does it need be known to others? > > Please stop trying to figure out what I am doing and just stick to the > feature being requested. Thank you! This is highly inappropriate. We are just volunteers. The 'you must do it because I want it' attitude is getting us nowhere. Feel free to come back when you decide to change your attitude and convince others that it's really useful and has many advantages over the tooling already available. Furthermore, it would be reasonable to tackle the PMS end first, so that Portage does not diverge from the defined EAPIs.
(In reply to Sergei Trofimovich from comment #3) > Because I don't understand the semantic difference between a > "set in world set" and a "set in profile". > > Both need to be added/switched-over explicitly and seem to do the same thing. That is a matter of how others chose to word various output. But a set in a world set, or in a profile, is no longer a set, but just a package list. It is not how its referred but how it is used. Once a set is added to a profile, it really is not so much a set anymore, but a list of packages added to that profile. A list which a user can then rebuild via @package_set.
(In reply to Michał Górny from comment #4) I have asked you several times to avoid commenting on anything I am involved with. I do not understand why you feel the need to get involved. I am looking to discuss this with others. I have purposes avoided you on list and did not reply to any of your posts. Which you proceed to then make the same comments and arguments on a bug. Stop, leave me alone!
(In reply to William L. Thomson Jr. from comment #5) > (In reply to Sergei Trofimovich from comment #3) > > Because I don't understand the semantic difference between a > > "set in world set" and a "set in profile". > > > > Both need to be added/switched-over explicitly and seem to do the same thing. > > That is a matter of how others chose to word various output. But a set in a > world set, or in a profile, is no longer a set, but just a package list. It > is not how its referred but how it is used. A set is not a package list, though...
(In reply to William L. Thomson Jr. from comment #5) > (In reply to Sergei Trofimovich from comment #3) > > Because I don't understand the semantic difference between a > > "set in world set" and a "set in profile". > > > > Both need to be added/switched-over explicitly and seem to do the same thing. > > That is a matter of how others chose to word various output. But a set in a > world set, or in a profile, is no longer a set, but just a package list. It > is not how its referred but how it is used. > > Once a set is added to a profile, it really is not so much a set anymore, > but a list of packages added to that profile. A list which a user can then > rebuild via @package_set. I'm afraid the above still makes almost no sense to me. Can you show a few examples or counter examples where existing system is not adequate and having sets would be beneficial? Something concrete, like "here I have such and such set defined in the following way and expect the <some properties> to hold when I maintain my system by running the following emerge commands". A few notes: - You can already create sets in repositories. Example is @yesod-platform in ::haskell overlay: https://github.com/gentoo-haskell/gentoo-haskell/blob/master/sets.conf - You can reuse the same package lists in various profiles by inheriting a profile that defines only a list of packages. ::gentoo's profiles/base/packages does exactly that. - (reiterating just in case) You can add sets to '/var/lib/portage/world_sets' as-is as @arch.
(In reply to Ciaran McCreesh from comment #7) > (In reply to William L. Thomson Jr. from comment #5) > > > > That is a matter of how others chose to word various output. But a set in a > > world set, or in a profile, is no longer a set, but just a package list. It > > is not how its referred but how it is used. > > A set is not a package list, though... My sets are simply that, a package list. https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/sets (In reply to Sergei Trofimovich from comment #8) > > I'm afraid the above still makes almost no sense to me. You may never understand what I am trying to do. I do not understand why you need to understand what another is doing. I do not need to understand what others are doing. If they have a request for something, I stick to that. > Can you show a few examples or counter examples where existing system is not > adequate and having sets would be beneficial? Again I should not have to show you to help you understand my needs and what I am trying to do. I want to use these in profiles https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/sets > - You can already create sets in repositories. Example is @yesod-platform in > ::haskell overlay: > https://github.com/gentoo-haskell/gentoo-haskell/blob/master/sets.conf I am > - You can reuse the same package lists in various profiles by inheriting a > profile that defines only a list of packages. ::gentoo's > profiles/base/packages does exactly that. Profile inheritance is jacked. Try inheriting profiles outside of portage. They all use relative paths and that breaks. Been there done that, run my own profiles. https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/profiles I want to use sets in MY profiles. I know the issue, and I am working around it as best I can. Next will be modifying portage python code myself for my needs. > - (reiterating just in case) You can add sets to > '/var/lib/portage/world_sets' as-is as @arch. I am already doing that. I realize you do not understand and I am not required to spend my time to help you understand. Managing world/world_set files across many systems is not feasible. Even using things like Ansible, it makes considerable work. It is MUCH easier to do it all in a profile and just update that for all systems. Just the same I have need for sets of packages. The same set in different profiles that DO not inherit the other profile. In funtoo terms, mix-ins. But this is not possible on Gentoo. Using sets in profiles is a means of doing mix-ins via profiles. Allows me to add sets of packages to various unrelated profiles. I find sets very useful and am using them more and more. Meta packages do not suffice the same, and have needless extra stuff that is not relevant, home page, license, keywords, etc. Plus sets need not be versioned, and other things you must do with ebuilds. This is really a simple thing, but others keep making it more complex. I have a need. You all can make this change or not. But wasting time in discussion and understanding is going no where. I want to use sets in profiles. Who cares what your understanding of that is. All that needs to be done is portage modified for such. There are other things that take place that you likely do not understand. We do not need to understand all things of others.
(In reply to William L. Thomson Jr. from comment #9) > > A set is not a package list, though... > > My sets are simply that, a package list. > https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/sets So you're not talking about using sets in profiles at all. You're talking about using your thing you call "package lists" in profiles, when you've not defined what a package list is. > This is really a simple thing, but others keep making it more complex. Using sets in profiles is not simple. You appear not to understand what sets are. > I want to use sets in profiles. Who cares what your understanding of that > is. Apparently you don't want to use sets in profiles, though, you want to use package lists (whatever those are) in profiles.
> My sets are simply that, a package list. > https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/sets ... > I want to use these in profiles > https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/sets It looks to me the goal here is to avoid package list duplication in two (or more) places: 1. Packages in a named set as defined by repository (as opposed to user's sets) [ to be able to handle them via 'emerge @foo ...' syntax. ] 2. Packages in user-defines profiles [ to pull packages in by default ] That makes more sense now. > > - You can reuse the same package lists in various profiles by inheriting a > > profile that defines only a list of packages. ::gentoo's > > profiles/base/packages does exactly that. > > > Profile inheritance is jacked. Try inheriting profiles outside of portage. > They all use relative paths and that breaks. Been there done that, run my > own profiles. > > https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/profiles A few unrelated to one another points: 1. If you are using your own profiles then brokenness of ::gentoo profiles is irrelevant. Relative path would all be relative to your overlay. 2. portage supports absolute paths to profiles with 'repo:path' syntax or ':path' syntax for current repo. Example of extending package masks for https://trofi.github.io/posts/201-masking-a-package-in-gentoo-overlay.html For example here we mix both local overlay and ::gentoo into a single overlay profile: https://github.com/trofi/overlay-selective-mask-in-gentoo/blob/master/profiles/hardened/linux/x86/selinux/parent
<PMS hat> Is this intended as a feature for profiles in a future EAPI, or a portage specific extension? </PMS hat>
(In reply to Ciaran McCreesh from comment #10) > (In reply to William L. Thomson Jr. from comment #9) > > > A set is not a package list, though... > > > > My sets are simply that, a package list. > > https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/sets > > So you're not talking about using sets in profiles at all. You're talking > about using your thing you call "package lists" in profiles, when you've not > defined what a package list is. No I am talking about sets. Why don't you give your definition of what a set is rather than questioning another. > > This is really a simple thing, but others keep making it more complex. > > Using sets in profiles is not simple. You appear not to understand what sets > are. Again I outlined on list what should be allowed for use of sets in profile. This is not the place to repeat that same discussion. All points you raise have already been addressed on list in that thread. > > I want to use sets in profiles. Who cares what your understanding of that > > is. > > Apparently you don't want to use sets in profiles, though, you want to use > package lists (whatever those are) in profiles. Yes I do, so they can also be merged as @my_set for rebuild and other purposes.
(In reply to Sergei Trofimovich from comment #11) > > My sets are simply that, a package list. > > https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/sets > ... > > I want to use these in profiles > > https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/sets > > It looks to me the goal here is to avoid package list duplication > in two (or more) places: > > 1. Packages in a named set as defined by repository (as opposed to user's > sets) > [ to be able to handle them via 'emerge @foo ...' syntax. ] > 2. Packages in user-defines profiles > [ to pull packages in by default ] > > That makes more sense now. Bingo, that is one of the reasons. > > > - You can reuse the same package lists in various profiles by inheriting a > > > profile that defines only a list of packages. ::gentoo's > > > profiles/base/packages does exactly that. > > > > > > Profile inheritance is jacked. Try inheriting profiles outside of portage. > > They all use relative paths and that breaks. Been there done that, run my > > own profiles. > > > > https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/profiles > > A few unrelated to one another points: > > 1. If you are using your own profiles then brokenness of ::gentoo profiles is > irrelevant. Relative path would all be relative to your overlay. I did not want to make my own profiles at first. It is next to impossible to inherit based on Gentoo profiles in another overlay/location. I maybe incorrect but I had lots of problems. Thus I ended up making my own, not dependent on anything outside my repo. > 2. portage supports absolute paths to profiles with 'repo:path' syntax or > ':path' syntax for current repo. Example of extending package masks for > https://trofi.github.io/posts/201-masking-a-package-in-gentoo-overlay.html > > For example here we mix both local overlay and ::gentoo into a single > overlay profile: > https://github.com/trofi/overlay-selective-mask-in-gentoo/blob/master/ > profiles/hardened/linux/x86/selinux/parent I was not aware of that, and it could help. But I do not want this stuff as profiles. I started out that way before I moved them to sets. I may use them in profiles, but just being a list of packages. Did not make as much sense for a profile. I really haven't the need for profiles outside of tree. The problem then comes mixing profiles. You can only have 1 profile, but unlimited sets. Thus using a profile + set, allows best of both. While retaining rebuild aspect of the set packages. Doing inheritance gets tricky, and you can only build a tree with inherited paths. Things cannot really overlay as you can mixing in stuff from sets. Mix-inx like Funtoo has is ideal, but Gentoo lacks that. Thus I am limited to a profile and sets.
(In reply to William L. Thomson Jr. from comment #13) > (In reply to Ciaran McCreesh from comment #10) > > (In reply to William L. Thomson Jr. from comment #9) > > > > A set is not a package list, though... > > > > > > My sets are simply that, a package list. > > > https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/sets > > > > So you're not talking about using sets in profiles at all. You're talking > > about using your thing you call "package lists" in profiles, when you've not > > defined what a package list is. > > No I am talking about sets. Why don't you give your definition of what a set > is rather than questioning another. Because sets are already a defined concept and they don't mean what you think they mean. Sets already exist, and they are not package lists.
(In reply to Ciaran McCreesh from comment #15) > > Because sets are already a defined concept and they don't mean what you > think they mean. Sets already exist, and they are not package lists. Will you stop seriously? Sets are not in the PMS. Do you have any documentation to support your comments? I think your interpretation differs from all others. This is not exherbo.... Sets are documented on Gentoo, which I have referenced. Every one mentions essentially a list of packages. https://wiki.gentoo.org/wiki//etc/portage/sets https://wiki.gentoo.org/wiki/Selected_set_(Portage) https://wiki.gentoo.org/wiki/System_set_(Portage) https://wiki.gentoo.org/wiki/World_set_(Portage) https://makuro.wordpress.com/2010/12/12/intro-to-portage-sets/ man emerge /^\s*set set A set is a convenient shorthand for a large group of packages. I am referencing and using them correctly on GENTOO using portage/emerge. Not some other...
(In reply to William L. Thomson Jr. from comment #16) > (In reply to Ciaran McCreesh from comment #15) > > > > Because sets are already a defined concept and they don't mean what you > > think they mean. Sets already exist, and they are not package lists. > > Will you stop seriously? Sets are not in the PMS. Do you have any > documentation to support your comments? I think your interpretation differs > from all others. This is not exherbo.... > > Sets are documented on Gentoo, which I have referenced. Every one mentions > essentially a list of packages. No, they are a list of package dependency specifications. That is an entirely different thing.
(In reply to Ciaran McCreesh from comment #17) > > No, they are a list of package dependency specifications. That is an > entirely different thing. Stop this is not a discussion on sets. You are NOT a Gentoo nor portage developer. Nor do you use Gentoo profiles. This has NOTHING to do with you. You are just trolling and spamming this bug. You have YET to provide a single link. Despite my explicit request for such last time. Exactly what is your interest in this bug and Gentoo? How does this effect you in any way? You seriously need to stop on this thread. It did not include you. You choose to come to this bug and start commenting. You need to stop.
(In reply to William L. Thomson Jr. from comment #18) > (In reply to Ciaran McCreesh from comment #17) > > > > No, they are a list of package dependency specifications. That is an > > entirely different thing. > > Stop this is not a discussion on sets. You are NOT a Gentoo nor portage > developer. Nor do you use Gentoo profiles. This has NOTHING to do with you. > You are just trolling and spamming this bug. You have YET to provide a > single link. Despite my explicit request for such last time. Your own first link already says it, in the first sentence. I quote: > For each file in /etc/portage/sets, a package set is created, defining a one-to-many relationship between a set name and an arbitrary group of package atoms.
(In reply to Ciaran McCreesh from comment #19) > (In reply to William L. Thomson Jr. from comment #18) > > (In reply to Ciaran McCreesh from comment #17) > > > > > > No, they are a list of package dependency specifications. That is an > > > entirely different thing. > > > > Stop this is not a discussion on sets. You are NOT a Gentoo nor portage > > developer. Nor do you use Gentoo profiles. This has NOTHING to do with you. > > You are just trolling and spamming this bug. You have YET to provide a > > single link. Despite my explicit request for such last time. > > Your own first link already says it, in the first sentence. I quote: > > > For each file in /etc/portage/sets, a package set is created, defining a one-to-many relationship between a set name and an arbitrary group of package atoms. That is a list of packages.... An arbitrary group of packages is a list... Again man emerge.... /^\s*set set A set is a convenient shorthand for a large group of packages. And again what is your interest? Why do you keep commenting here? Take your comments to the mailing list. This is a bug opened for portage developers. Which you are not one. Stop spamming people with your non-sense. Go do something on Exherbo. Do you even run Gentoo? Why are you here and commenting?
(In reply to William L. Thomson Jr. from comment #20) > (In reply to Ciaran McCreesh from comment #19) > > (In reply to William L. Thomson Jr. from comment #18) > > > (In reply to Ciaran McCreesh from comment #17) > > > > > > > > No, they are a list of package dependency specifications. That is an > > > > entirely different thing. > > > > > > Stop this is not a discussion on sets. You are NOT a Gentoo nor portage > > > developer. Nor do you use Gentoo profiles. This has NOTHING to do with you. > > > You are just trolling and spamming this bug. You have YET to provide a > > > single link. Despite my explicit request for such last time. > > > > Your own first link already says it, in the first sentence. I quote: > > > > > For each file in /etc/portage/sets, a package set is created, defining a one-to-many relationship between a set name and an arbitrary group of package atoms. > > That is a list of packages.... An arbitrary group of packages is a list... An atom and a package are entirely different things.
Get out of her(In reply to Ciaran McCreesh from comment #21) > > An atom and a package are entirely different things. You are a serious troll. Do you run Gentoo? Are you a portage Developer? Why are you even commenting on this bug? Again go man emerge. Oh wait you cannot because you do not even run Gentoo... /^\s*set set A set is a convenient shorthand for a large group of packages. I have emailed a link to this bug to The University of Glasgow, along with some comments on your behaviour on this bug. Clearly you have no idea about sets as you are not a Gentoo user or developer. You are just a Gentoo troll. Don't you have your own distro exherbo and your own package manager? You have your own bugs to work. Go some where else.
(In reply to William L. Thomson Jr. from comment #22) > Get out of her(In reply to Ciaran McCreesh from comment #21) > > > > An atom and a package are entirely different things. > > > You are a serious troll. Do you run Gentoo? Are you a portage Developer? Why > are you even commenting on this bug? > > > Again go man emerge. Oh wait you cannot because you do not even run Gentoo... > > /^\s*set > set A set is a convenient shorthand for a large group of > packages. As you can clearly see from, e.g. the system set on your own Gentoo system, sets are lists of package dependency specifications (the term atom is a historical term not used in PMS due to them not being atomic), not lists of packages.
(In reply to Ciaran McCreesh from comment #23) > > As you can clearly see from, e.g. the system set on your own Gentoo system, > sets are lists of package dependency specifications (the term atom is a > historical term not used in PMS due to them not being atomic), not lists of > packages. Why do you keep commenting on a bug? This is NOT the place for discussion. There is a mailing list for that. This was already discussed at length to death on list. No one else is participating in, nor agreeing with the points you are making. You do not run Gentoo. Clearly you have NOTHING better to do with your time, but troll this bug. I am sure others who are being spammed by all this really appreciate it. I would not be commenting, if you were not. Please STOP and let others comment on THEIR bug. This bug is not yours. You have no affiliation with Gentoo. Again do you run Gentoo? Are you a Gentoo User? Are you a Gentoo Developer? Why are you here? Clearly Gentoo needs to ditch the PMS. Then you have no reason to be around here.
(In reply to William L. Thomson Jr. from comment #24) > (In reply to Ciaran McCreesh from comment #23) > > > > As you can clearly see from, e.g. the system set on your own Gentoo system, > > sets are lists of package dependency specifications (the term atom is a > > historical term not used in PMS due to them not being atomic), not lists of > > packages. <comrel hat> <snip> > Why do you keep commenting on a bug? This is NOT the place for discussion. > You do not run Gentoo. > Clearly you have NOTHING better to do with your time, but troll this bug. I > am sure others who are being spammed by all this really appreciate it. > This bug is not yours. You have no affiliation with Gentoo. </much snips above> As you've stated above, this is not the place for discussions and neither of you "run Gentoo". Also, I'm sure some of those getting the emails might read your (wltjr) comments as spam as well. Neither of you are "entitled" to use (and abuse) bugzilla, and the courtesy we extend applies to both, so please stop acting as if you (wltjr) have an "entitlement" that ciaranm doesn't have. </comrel hat> I'll let the portage and pms teans address (further) the specific points raised on this bug.
(In reply to Ulrich Müller from comment #12) > <PMS hat> > Is this intended as a feature for profiles in a future EAPI, or a portage > specific extension? > </PMS hat> No reply. PMS is out of here.
(In reply to Jorge Manuel B. S. Vicetto from comment #25) > As you've stated above, this is not the place for discussions and neither of > you "run Gentoo". Um YES I run Gentoo.... Why do you think I opened this bug? That is just common sense.... That I use an overlay on top due to packages I need not being in Gentoo. Does not mean I am not using Gentoo. I do not run Funtoo or any derivatives. I have a need for using Gentoo sets in Gentoo profiles. So what if they are my sets and my profiles. Its all Gentoo stuff.... Why would I be mirroring this and having it synced daily if I was not using it? I did switch over to git for when I submitted PRs. But I was encouraged to stop contributing to Gentoo. Thus I just open some bugs, post on list etc. https://github.com/Obsidian-StudiosInc/gentoo I am not discussing things here. I opened a bug on a technical request after a discussion took place on a mailing list. Which any further discussion should be there. It is others comments on the technical bug I opened that should not exist. Then there would be no replies from me... Do not mix the bug reporter with some person who just chooses to comment because they are involved in PMS. Which really should not dictate Gentoo portage development. But the other way around. PMS has not been good for Gentoo at all. This situation is a perfect example.
(In reply to Ulrich Müller from comment #26) > (In reply to Ulrich Müller from comment #12) > > <PMS hat> > > Is this intended as a feature for profiles in a future EAPI, or a portage > > specific extension? > > </PMS hat> > > No reply. PMS is out of here. Since others ignored, I will comment. I think this would be at first a portage specific extensions. It seems sets is a bit ambiguous and the PMS at this time does not seem to cover "sets" at all. Other than using the word sets in places. I am not really interested in the PMS. If other package managers have and support this is moot to me. This is something portage/emerge specific, since I am not using any other package manager. Seems adding it to the PMS would take some time, if that even happens. It seems the use of sets with regard to portage/emerge is already a bit different than somes interpretation of sets. To me it seems it is already some sort of portage extension. Unless other package managers also support like /etc/portage/sets. I may see about making a patch for such functionality time permitting, and depending on how much I need to use sets in profiles.
(In reply to William L. Thomson Jr. from comment #27) > PMS has not been good for Gentoo at all. This situation is a perfect example. See? That attitude is precisely the reason why PMS shouldn't be in CC here. :(
(In reply to Ulrich Müller from comment #29) > (In reply to William L. Thomson Jr. from comment #27) > > PMS has not been good for Gentoo at all. This situation is a perfect example. > > See? That attitude is precisely the reason why PMS shouldn't be in CC here. > :( Given that PMS does not cover the topic of sets at all in any form. It is causing an issue here where if there were no PMS. We could simply discuss portage features and what maybe best for the Gentoo community and end users. Sets seem to be more for end users. But that PMS does not mention them at all. It could be stated portage cannot do anything with sets in profiles due to it not being in PMS. Which is a specification holding back development. I am a developer. I develop many things without such specification. I am fine with such things as long as they benefit things. But in this case seems like a hindrance. I have been around Gentoo since before PMS, and over the years it has existed and EAPI. I am not sure it has really benefited Gentoo as it was thought to conceptually. What is wrong with re-evaluating things? Not all things work as intended. Back when PMS came about I could use say paludis alongside portage. That maybe the case still with pkgcore. Last time I checked out paludis. It required such major changes it seemed I would break portage/emerge in the process. Not wanting to hose my system, or have to resurrect portage environment from some fubar. I decided to not mess with paludis. Back in 2007 it was part of my workflow as a developer, using it alongside repoman before any commits, for variety of purposes. Paludis has deviated so much, it cannot be used alongside portage easily if at all like it once was. I do not see that many showing interest in alternative package managers. It seems most if not all run portage/emerge. Not sure the interest on pkgcore but that it seems it lacks support for EAPI 6. Its not really a current package manager. Thus if paludis and pkgcore cannot be used. What other package manager is there for Gentoo? What other purpose is there for PMS? I just do not see how PMS is benefiting portage/emerge development. Does not seem like the core developers there are participating in PMS. Which is odd for a variety of reasons. They are responsible for the implementation on Gentoo but not part of the process. Not hating on PMS, just seems to hold back development more than expedite. I rather see things that expedite development as a developer.
The signal to noise ratio is too low in this bug to be actionable.
