$summary
Hello Agostino. You have just dropped a bunch of fresh Bugzilla issues into my lap without so much as a summary. Please add comments for each one, distinguishing between feature requests and actual bugs, explaining what particular problems you see in each case. Thanks.
Hello Ralph, if something misses on the bug, the correct behavior is just ask, not assign the bug to the requester. Don't see me as hostile, maybe the bug is not verbose at all, but if you don't understand what's the issue here I'd suggest to familiarize a bit with the ebuilds and the Gentoo World. The configure allows you to decide if you want to enable ipv6 support or not. I don't see the relative IUSE, so you should add an IUSE which control the ipv6 support.
(In reply to Agostino Sarubbo from comment #2) > if something misses on the bug, the correct behavior is just ask, not > assign the bug to the requester. Actually, the correct behaviour is to file self-sufficient reports, i.e. ones that don't leave the assignee guessing. :-) > Don't see me as hostile, maybe the bug is not verbose at all, but if > you don't understand what's the issue here I'd suggest to familiarize > a bit with the ebuilds and the Gentoo World. Also not meaning to be hostile: While I can (and do) always learn more about ebuilds, it is not my job to guess what you mean. You need to take time time to describe each issue in a reasonably complete manner. We're all volunteers, and my time is as valuable as yours, so I won't process incomplete reports. > The configure allows you to decide if you want to enable ipv6 support or > not. I don't see the relative IUSE, so you should add an IUSE which control > the ipv6 support. Now that's something to go on. Please update all other bug reports in a similar fashion. I have doubts about whether or not IPv6 support should be controlled by a USE flag. https://devmanual.gentoo.org/general-concepts/use-flags/index.html states "USE flags are to control optional dependencies and settings which the user may reasonably want to select." Given that NGINX-Unit, by its very nature, needs mechanisms that allow clients to connect, is it really a good idea to disable IPv6 support?
(In reply to Ralph Seichter from comment #3) > is it really a good idea to disable IPv6 support? ago@spectre ~ $ equery h ipv6 -p | wc -l 544 Hoping that I don't need to explain the command, you should give users a way to choice. Nobody talked about disable ipv6.
(In reply to Agostino Sarubbo from comment #4) > Hoping that I don't need to explain the command, you should give > users a way to choice. The day I need you to explain shell commands to me would be a memorable one. :-) > Nobody talked about disable ipv6. Then what *do* you talk about? I think IPv6 support should be always on these days, and Unit only allows to explicitly turn it off. My point stands: If you want changes made, please explain in detail why.
(In reply to Ralph Seichter from comment #5) > Then what *do* you talk about? I think IPv6 support should be always on > these days, and Unit only allows to explicitly turn it off. > > My point stands: If you want changes made, please explain in detail why. It looks like you are kidding me. You need to add the IUSE to control ipv6 support. Stop.
(In reply to Agostino Sarubbo from comment #6) > It looks like you are kidding me. Not at all. > You need to add the IUSE to control ipv6 support. Stop. In Unit, IPv6 is enabled by default, as it should be. A USE flag could only be used to disable it, but I don't think IPv6 support should be disabled. So, if you still think I "need" to do something, please convince me by offering your reasoning.
I don't have to convince anyone, instead you should read the devmanual: https://devmanual.gentoo.org/general-concepts/use-flags/index.html If you didn't find the relevant part, feel free to ask.
(In reply to Agostino Sarubbo from comment #8) > I don't have to convince anyone, instead you should read the devmanual I did. I have even quoted the dev manual, explaining why I don't consider adding a USE flag in this case a good idea. Now you can either convince me, or this bug will be closed. I have spent enough time explaining my point.
You have quoted the right part but you have failed to understand it. EVERYTHING CONTROLLABLE BY THE CONFIGURE MUST HAVE AN IUSE, so since we are talking about an IUSE already present more than 500 times, I don't see why here it should be an exception.
(In reply to Agostino Sarubbo from comment #10) > You have quoted the right part but you have failed to understand it. One more arrogant outburst of yours like this one, and we're done! > EVERYTHING CONTROLLABLE BY THE CONFIGURE MUST HAVE AN IUSE Where exactly does the dev manual state that? I don't see it, so please quote. Also, this is a case where I think "When not to use USE flags?" applies.
(In reply to Ralph Seichter from comment #11) > Where exactly does the dev manual state that? I don't see it, so please > quote. It is the first sentence in the link: "USE flags are to control optional dependencies and settings which the user may reasonably want to select." > Also, this is a case where I think "When not to use USE flags?" applies. Atm, ipv6 is an optional support, and we are not talking about something particular, infact ipv6 is a global USE: https://www.gentoo.org/support/use-flags/ Also, you should see the common behavior because do something and say: "this is a case where I think "When not to use USE flags?" applies"
(In reply to Agostino Sarubbo from comment #12) > It is the first sentence in the link: "USE flags are to control optional > dependencies and settings which the user may reasonably want to select." That does not mean that *every* configure option needs to be exposed by means of a USE flag, which is what you erroneously claimed in #c10. As explained before, I don't consider IPv6 support something the ebuild should provide a choice for. These days, IPv6 is a must as far as I am concerned, so I don't think providing an off-switch is reasonable. > Also, you should see the common behavior because do something and say: "this > is a case where I think "When not to use USE flags?" applies" I realize that English is neither your nor my native language, but I am sorry to say this makes no sense to me. It is not even a sentence, and I don't know what you are trying to say, sorry. Having spent a lot of time on this, I am still convinced my reasoning is sound. You and I will need to "agree to disagree", and I will now close this bug report.
@qa: sorry for the noise, can you say something here? Thanks
I'd say it's gray zone. For ipv6, I'd add the flag since we use it globally (but I wouldn't insist if upstream didn't have the switch). Ralph, if you believe we should be making IPv6 unconditionally globally, I think this should be discussed first and if others agree with you, we should aim for removing the flag globally. Otherwise, it's a confusing inconsistency.
(In reply to Michał Górny from comment #15) > I'd say it's gray zone. Tell me about it. ;-) > For ipv6, I'd add the flag since we use it globally > (but I wouldn't insist if upstream didn't have the switch). IPv6 is enabled by default in the upstream build; it only has a `--no-ipv6` configure switch to explicitly disable IPv6 support. I am convinced that should not be done in this day and age. > Ralph, if you believe we should be making IPv6 unconditionally globally, > I think this should be discussed first [...] I did not (and do not) suggest to do it globally. This is one particular ebuild where disabling any form of networking support--be it IPv4, IPv6 or local sockets--does not make sense at all. If a user forgets to enable an access method, he will only realize this when presented with error messages when the service is actually run. That means adding USE flags and recompiling, rinse and repeat. That, from my understanding, is what ebuilds should avoid, according to the dev manual. I see adding this USE flag as nothing but a potential means for users to make annoying mistakes.
(In reply to Michał Górny from comment #15) > I'd say it's gray zone. For ipv6, I'd add the flag since we use it globally > (but I wouldn't insist if upstream didn't have the switch). I agree, infact upstream has the switch. (In reply to Ralph Seichter from comment #16) > IPv6 is enabled by default in the upstream build; it only has a `--no-ipv6` > configure switch to explicitly disable IPv6 support. I am convinced that > should not be done in this day and age. Your conviction comes only from the usage you are doing on *your* systems. I'm not saying to disable ipv6, I'm just saying to let the users decide based on their needs. Since I do not have ipv6 here I don't see why I should run unit with ipv6 > If a user forgets to enable an > access method, he will only realize this when presented with error messages > when the service is actually run. That means adding USE flags and > recompiling, rinse and repeat. That, from my understanding, is what ebuilds > should avoid, according to the dev manual. I see adding this USE flag as > nothing but a potential means for users to make annoying mistakes. This is how Gentoo works. Your idea looks great for a packaging distro where is maintainer's responsibility avoid mistakes. I will use unit for production purpose. The bugs I've filed were for improving purpose, but your are convincing me that unit is packaged based on your needs. So, since I'm not asking to remove anything, I really don't understand your behavior. Anyway that's fine, I can package it by myself and run from a local overlay.
(In reply to Agostino Sarubbo from comment #17) > Your conviction comes only from the usage you are doing on *your* systems. Frankly, you have no idea where my conviction originates, so don't presume to be able to read my mind. I find your tone in this discussion unnecessarily confrontational and unbecoming. The current version of the ebuild maintainer quiz actually contains questions asking when *not* to utilize USE flags. > Since I do not have ipv6 here I don't see why I should run unit with ipv6 Nobody is forcing you to do so. If you look into the ebuild, you'll find that IPv6 is deliberately not listed in the dependencies, and merging the ebuild will not install additional libraries. > Anyway that's fine, I can package it by myself and run from a local overlay. Sure, fine by me. Case closed.
