On Wed, Dec 7, 2016 at 5:16 PM, Michał Górny <mgo...@gentoo.org> wrote: > On Wed, 7 Dec 2016 16:16:45 +0800 > konsolebox <konsole...@gmail.com> wrote: > >> On Wed, Dec 7, 2016 at 1:23 PM, Michał Górny <mgo...@gentoo.org> wrote: >> > On Tue, 6 Dec 2016 20:11:34 -0600 >> > William Hubbs <willi...@gentoo.org> wrote: >> > >> >> On Tue, Dec 06, 2016 at 05:26:19PM -0500, Mike Gilbert wrote: >> >> > On Tue, Dec 6, 2016 at 4:15 PM, Michał Górny <mgo...@gentoo.org> wrote: >> >> > > On Tue, 6 Dec 2016 12:54:26 -0500 >> >> > > Mike Gilbert <flop...@gentoo.org> wrote: >> >> > > >> >> > >> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox <konsole...@gmail.com> >> >> > >> wrote: >> >> > >> > Please consider promoting the use of tinfo flag in packages that >> >> > >> > depend on sys-libs/ncurses so that they would synchronize properly >> >> > >> > with sys-libs/ncurses[tinfo]. >> >> > >> >> >> > >> I would rather see the tinfo USE flag removed from ncurses. >> >> > > >> >> > > vapier doesn't consider this QA violation a QA violation. >> >> > > >> >> > > https://bugs.gentoo.org/487844 >> >> > >> >> > Perhaps QA could take some action then? >> >> > >> >> > Updating ~1500 ebuilds with a [tinfo=] use-dep seems like a poor >> >> > solution. >> >> >> >> <qa hat on> >> >> Our policies are in the dev manual, so please cite the violation there. >> >> If you can't, this is not a qa violation, so please don't call it one. >> >> </qa hat> >> >> >> >> I don't see a problem with the use flag and suggest updating the other >> >> ebuilds. >> > >> > The flag randomly changes ABI, breaking all reverse dependencies. >> > Please tell me this is a good practice. >> >> And there you had just proven that the ncurses package is installed in >> two modes, showing that a flag like tinfo is needed to represent them. >> It's not the ncurses package's fault. It's the depending packages' >> responsibility to properly adapt to it. > > Packages are not intelligent beings, so they can't have responsibility.
Of course. > Package maintainers have. You can't expect people to spend a lot of > time updating a lot of packages every time a new ABI-breaking flag is > suddenly introduced in a core package, if it's not even clear if it > going to stay long-term. So you're suggesting to wait and keep things [partly] broken until then. Why not fix things first then remove the [-tinfo] feature when everything no longer needs it instead. This is even just a one-time solution, and is not much different with the massive number of pkg-config patches currently being implemented among ebuilds. (Again, I'm not exactly liking the use of pkg-config. I'd rather have a simple export since it's good enough, easier to implement, less compromising with the source, and is more universal.) > Not to mention the USE flag will be a true PITA for our users. Just > imagine all the conflicts when one package doesn't support > ncurses[tinfo], or the other way around... Better show the conflicts than allow users to "shoot themselves in the foot" without even knowing it. I'd rather solve those issues than "trust" that everything would just work without knowing it, or fix a package everytime I see a breakage. Consistency comes first before anything else, otherwise you're applying an incomplete solution or a workaround. >> Basically you're suggesting to drop either of those modes. Now I'm >> asking, would one of those (likely tinfo mode) be workable in all >> packages? Do you find that it would cause less issues than this >> solution? And I'm talking about end-user issues, not ebuild >> implementation issues. > > Yes. If I recall correctly, libncurses links to libtinfo, so packages > already built continue to work. Of course, new packages (including deps > of the libraries already linked to libncurses) may fail to build. > > Remember that binary distros have to make a choice. This is Gentoo. Consider reading the first two lines in https://gentoo.org/get-started/about/. > I can understand > keeping the flag to help people migrate more gracefully when building > from source. But it's not a way to run things long-term. Long-term about? >> I find that forcing depending packages to follow that mode sounds >> worse than what you claim a QA violation. > > Really? Because 'choice' or do you have a better argument than that? I didn't get that. Please be less ambiguous. Note that I didn't imply there that I agree with your idea. The use of tinfo in ncurses is a correct uncompromising solution. The one questionable is forcing packages to work with [tinfo], because there may be cases where it could resort to too much patching that it already becomes a hack. -- konsolebox
