Re: [gentoo-dev] tinfo flag

[Michał Górny]

On Wed, 7 Dec 2016 16:16:45 +0800
konsolebox <konsolebox@×××××.com> wrote:

> On Wed, Dec 7, 2016 at 1:23 PM, Michał Górny <mgorny@g.o> wrote:
> > On Tue, 6 Dec 2016 20:11:34 -0600
> > William Hubbs <williamh@g.o> 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 <mgorny@g.o> wrote:
> >> > > On Tue, 6 Dec 2016 12:54:26 -0500
> >> > > Mike Gilbert <floppym@g.o> wrote:
> >> > >
> >> > >> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox <konsolebox@×××××.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