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. 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. 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... > 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. 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. > 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? -- Best regards, Michał Górny
pgpsE1ywyNM1i.pgp
Description: OpenPGP digital signature
