Re: [gentoo-dev] tinfo flag

[Ian Stakenvicius]

On 07/12/16 05:40 AM, konsolebox wrote:
> On Wed, Dec 7, 2016 at 5:16 PM, Michał Górny <mgorny@g.o> wrote:
>> 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.
>
> 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.)
>

Here's the thing -- ncurses provides all functionality regardless of
whether it's split into two libs (libncurses+libtinfo) or not.  So
what this flag is really doing is providing the capability of linking
to just part of ncurses instead of all of it, if a project desires.
And projects(binary ones at that) are doing this, which is why we have
some deps that require the tinfo flag to be enabled currently.

There is only one instance of a dependency atom that requires the
tinfo flag to be disabled, and that package is an old game whos build
system and ebuild is flawed in this regard.  All others are fine with
the flag being enabled so far as I can tell (and if they're not then
it's a bug that needs to be addressed anyhow).

SO, in summary, it would seem to make sense (since anything prebuilt
will work as-is, and anything compiled will be built to work with it)
to remove the tinfo flag but force libtinfo to be built and installed
-- simply make it non-optional.  Additionally, we can set
SLOT="0/6tinfo" which will trigger subslot rebuilds to ensure anything
that may need to be rebuilt to link to both libncurses and libtinfo
will be rebuilt when the tinfo-IUSE-less version gets installed.

We not only have a solution that'll address the
ABI-break-on-USE-change issue, but also a migration path that will be
transparent to users via a -uDN @world.  I call that a win-win.  The
only thing we lose is the easy ability to build an all-in-one
libncurses.  So if there is an actual need for that which we have yet
to find, this is an official request for comments to let us know.