Re: [gentoo-dev] tinfo flag

[Daniel Campbell]

On 12/07/2016 07:27 AM, Ian Stakenvicius wrote:
> On 07/12/16 05:40 AM, konsolebox wrote:
>> On Wed, Dec 7, 2016 at 5:16 PM, Michał Górny  wrote:
>>> On Wed, 7 Dec 2016 16:16:45 +0800
>>> konsolebox  wrote:
>>>
 On Wed, Dec 7, 2016 at 1:23 PM, Michał Górny  wrote:
> On Tue, 6 Dec 2016 20:11:34 -0600
> William Hubbs  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  wrote:
 On Tue, 6 Dec 2016 12:54:26 -0500
 Mike Gilbert  wrote:

> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox  
> 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.
>>
>> 
>> 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.
>> 
>>
>> 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.
> 
> 
Thanks for adding some clarity to the conversation. Your idea seems
solid to me; if libtinfo and libncurses are built from the same repo, we
can ship ncurses with the included libtinfo build and, if it's needed in
the future, write an ebuild for just libtinfo (similar to how udev can
be built separate from systemd). Based on what I've seen in this thread,
there isn't a need (yet) for tinfo to be standalone, so I support
bundling them 

Re: [gentoo-dev] tinfo flag

[Pacho Ramos]

El mié, 07-12-2016 a las 10:27 -0500, Ian Stakenvicius escribió:
> 
[...]
> 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).
> 

Looking to this tracker bug there would be more packages needing to be
fixed (and probably a more recent tinderbox would be needed)
https://bugs.gentoo.org/show_bug.cgi?id=457530

But looking more deeply to Fedora and openSuSE, they seem to not face
this breakage even enabling tinfo :/, but, at least on openSuSE, they
seem to play some "black magic" in the ncurses .pc files to probably
not cause this issue as I see in their .spec file:
http://download.opensuse.org/tumbleweed/repo/src-oss/suse/src/ncurses-6
.0-16.1.src.rpm

Re: [gentoo-dev] tinfo flag

[Alexis Ballier]

On Wed, 7 Dec 2016 10:16:47 +0100
Michał Górny  wrote:
> > 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.


So ncurses -> ncurses[tinfo] is not breaking.
ncurses[tinfo] -> ncurses breaks ABI all apart.

Still a bad idea to have this randomly switchable.

Having the useflag around is not wrong, but we should definitely force
one state by pacakge.use.mask/force. People that want to experiment
should know what they're doing. Remember libcxx on fbsd, right ?


Alexis.

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




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] tinfo flag

[Pacho Ramos]

El mar, 06-12-2016 a las 22:15 +0100, Michał Górny escribió:
> On Tue, 6 Dec 2016 12:54:26 -0500
> Mike Gilbert  wrote:
> 
> > 
> > On Mon, Dec 5, 2016 at 6:13 AM, konsolebox 
> > 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
> 

Well, I think I have seen other packages with this similar behavior...
perl[ithreads] I think is one of them :/ Then, I wouldn't focus this in
a fight between QA violations or not :| Otherwise we will end up with
endless arguments focusing on this fights instead of trying to handle
the concrete issue.

I agree that this is really ugly... but probably we would need to
handle each case in particular. The problem is that I don't know what
is the correct approach for this case... I would think about enabling
tinfo always... but probably it breaks reverse deps badly :/ Anyway, I
think Fedora is enabling it always, then, it shouldn't be too hard. 

What people from base-system think about this? What is the advantage of
allowing people to switch this behavior?

Re: [gentoo-dev] tinfo flag

[konsolebox]

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

Re: [gentoo-dev] tinfo flag

[Michał Górny]

On Wed, 7 Dec 2016 16:16:45 +0800
konsolebox  wrote:

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

Re: [gentoo-dev] tinfo flag

[konsolebox]

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

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.

I find that forcing depending packages to follow that mode sounds
worse than what you claim a QA violation.

-- 
konsolebox

Re: [gentoo-dev] tinfo flag

[konsolebox]

On Wed, Dec 7, 2016 at 6:26 AM, Mike Gilbert  wrote:
> Updating ~1500 ebuilds with a [tinfo=] use-dep seems like a poor solution.

If it's the only consistent solution, either you go for it,
compromise, or be contented that it's half-broken.  I'm not a fan of
the latter 2.  Or maybe we can /hopefully/ wait for a non-workaround
solution in the future EAPI, which I doubt could be provided.

I'm not a developer, but I can volunteer to make some of the changes.
I'll just place the packages in a public repo.  Just promise me my
effort won't go to waste.

Doing gradual changes only for every ebuild version bump is not a bad
thing either, since that's even what is happening right now.

Maybe we can create an eclass to make some changes easier (if
applicable and useful), and/or debate whether the use of pkg-config
over a simple `use tinfo` test and an `export` is effectively better
in this context.

-- 
konsolebox

Re: [gentoo-dev] tinfo flag

[Daniel Campbell]

On 12/06/2016 06:44 PM, Mike Gilbert wrote:
> On Tue, Dec 6, 2016 at 9:11 PM, William Hubbs  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  wrote:
 On Tue, 6 Dec 2016 12:54:26 -0500
 Mike Gilbert  wrote:

> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox  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.
>>
>> 
>> 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.
>> 
>>
>> I don't see a problem with the use flag and suggest updating the other 
>> ebuilds.
> 
> The USE flag introduces needless complexity for zero benefit. Please
> explain to me why this is a good idea.
> 
As an onlooker, I don't see anything in favor of getting rid of it, and
otherwise it seems like a normal USE flag. All that's been said in favor
of removing it is just statements that tell me it's more complex or that
it's a QA violation.

Could you explain so other people (and myself) understand what you're
talking about?
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] tinfo flag

[Michał Górny]

On Tue, 6 Dec 2016 20:11:34 -0600
William Hubbs  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  wrote:  
> > > On Tue, 6 Dec 2016 12:54:26 -0500
> > > Mike Gilbert  wrote:
> > >  
> > >> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox  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.  
> 
> 
> 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.
> 
> 
> 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.

But yeah, Gentoo lately is: everything with a single bit of sense has
to be converted into 3-page manual that covers every corner case,
and eventually has 5 ways for every developer to ignore it.

-- 
Best regards,
Michał Górny



pgpG_utiyJb9D.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] tinfo flag

[Mike Gilbert]

On Tue, Dec 6, 2016 at 9:11 PM, William Hubbs  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  wrote:
>> > On Tue, 6 Dec 2016 12:54:26 -0500
>> > Mike Gilbert  wrote:
>> >
>> >> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox  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.
>
> 
> 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.
> 
>
> I don't see a problem with the use flag and suggest updating the other 
> ebuilds.

The USE flag introduces needless complexity for zero benefit. Please
explain to me why this is a good idea.

Re: [gentoo-dev] tinfo flag

[William Hubbs]

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  wrote:
> > On Tue, 6 Dec 2016 12:54:26 -0500
> > Mike Gilbert  wrote:
> >
> >> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox  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.


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.


I don't see a problem with the use flag and suggest updating the other ebuilds.

William


signature.asc
Description: Digital signature

Re: [gentoo-dev] tinfo flag

[Mike Gilbert]

On Tue, Dec 6, 2016 at 4:15 PM, Michał Górny  wrote:
> On Tue, 6 Dec 2016 12:54:26 -0500
> Mike Gilbert  wrote:
>
>> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox  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.

Re: [gentoo-dev] tinfo flag

[Michał Górny]

On Tue, 6 Dec 2016 12:54:26 -0500
Mike Gilbert  wrote:

> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox  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

-- 
Best regards,
Michał Górny



pgpCEaoyqRkSI.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] tinfo flag

[konsolebox]

On Wed, Dec 7, 2016 at 2:17 AM, Mike Gilbert  wrote:
> On Tue, Dec 6, 2016 at 1:05 PM, konsolebox  wrote:
>> On Wed, Dec 7, 2016 at 1:54 AM, Mike Gilbert  wrote:
>>> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox  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.
>>
>> There are people who use packages that rely on sys-libs/ncurses[tinfo].
>
> So we should either:
>
> 1. Always enable tinfo.
> 2. Always disable tinfo, but install a binary compatibility symlink:
>
> /lib/libtinfo.so.6 -> libncurses.so.6

If that's certain not to cause issues now or in the future, and is
workable in all depending packages, then I'm ok with it.

-- 
konsolebox

Re: [gentoo-dev] tinfo flag

[Mike Gilbert]

On Tue, Dec 6, 2016 at 1:05 PM, konsolebox  wrote:
> On Wed, Dec 7, 2016 at 1:54 AM, Mike Gilbert  wrote:
>> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox  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.
>
> There are people who use packages that rely on sys-libs/ncurses[tinfo].

So we should either:

1. Always enable tinfo.
2. Always disable tinfo, but install a binary compatibility symlink:

/lib/libtinfo.so.6 -> libncurses.so.6

Re: [gentoo-dev] tinfo flag

[konsolebox]

On Wed, Dec 7, 2016 at 1:54 AM, Mike Gilbert  wrote:
> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox  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.

There are people who use packages that rely on sys-libs/ncurses[tinfo].

-- 
konsolebox

Re: [gentoo-dev] tinfo flag

[konsolebox]

On Wed, Dec 7, 2016 at 1:12 AM, Ian Stakenvicius  wrote:
> On 05/12/16 06:13 AM, konsolebox wrote:
>> Hi,
>>
>> 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].
>>
>> It could be as simple as:
>>
>> IUSE="tinfo"
>>
>> RDEPEND="sys-libs/ncurses[tinfo=]"
>>
>> pkg_setup() {
>> use tinfo && export LDFLAGS="-ltinfo ${LDFLAGS}" LIBS="-ltinfo ${LIBS}"
>> }
>>
>> The last line can be changed/enhanced, depending on the package.
>>
>> It helps keep binaries consistent even if sys-libs/ncurses[-tinfo]
>> gets recompiled to sys-libs/ncurses[tinfo], because they are forced to
>> be recompiled.  This is better than hard-coded dynamic workarounds.
>>
>
> Should this message perhaps have been directed to a particular set of
> developers or package maintainers rather than everyone on this list?

Sorry, I just thought it's better to send it to the list first.  I
already created a bug report for it (#601764).  It was rejected right
away for a reason not related to the main point.  I also made a reply
in #457530.

> I'm not sure what our stance is on propagating USE flags to rdeps when
> the package itself doesn't care (except due to the --libs output
> changing from pkg-config).  I feel that adding tinfo to IUSE the way
> it's suggested here might be the only technical solution right now,
> but at the same time it seems like something that might be better
> suited to something that should be addressed through other mechanisms
> in a future-EAPI...

Yes I thought a better solution can be provided in a future EAPI, like
perhaps a 
force-rebuild-everything-that-depends-on-the-package-if-flag-usage-changes,
but I'd rather not wait for it.  A new mechanism like that might also
force rebuilding of packages that don't rely on the features of
libtinfo.  An explicit declaration that a package wants tinfo like
sys-libs/ncurses[tinfo=] is better.

> Note in particular though that the pkg_setup example ISN'T imo a good
> idea -- rather, pkg-config should be used, as it will return the
> appropriate --libs output whether ncurses is built with USE=tinfo
> enabled or not.

Yes, I also said in my reply that pkg-config can be used for more accuracy.

-- 
konsolebox

Re: [gentoo-dev] tinfo flag

[Mike Gilbert]

On Mon, Dec 5, 2016 at 6:13 AM, konsolebox  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.

Re: [gentoo-dev] tinfo flag

[Ian Stakenvicius]

On 05/12/16 06:13 AM, konsolebox wrote:
> Hi,
> 
> 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].
> 
> It could be as simple as:
> 
> IUSE="tinfo"
> 
> RDEPEND="sys-libs/ncurses[tinfo=]"
> 
> pkg_setup() {
> use tinfo && export LDFLAGS="-ltinfo ${LDFLAGS}" LIBS="-ltinfo ${LIBS}"
> }
> 
> The last line can be changed/enhanced, depending on the package.
> 
> It helps keep binaries consistent even if sys-libs/ncurses[-tinfo]
> gets recompiled to sys-libs/ncurses[tinfo], because they are forced to
> be recompiled.  This is better than hard-coded dynamic workarounds.
> 

Should this message perhaps have been directed to a particular set of
developers or package maintainers rather than everyone on this list?

I'm not sure what our stance is on propagating USE flags to rdeps when
the package itself doesn't care (except due to the --libs output
changing from pkg-config).  I feel that adding tinfo to IUSE the way
it's suggested here might be the only technical solution right now,
but at the same time it seems like something that might be better
suited to something that should be addressed through other mechanisms
in a future-EAPI...

Note in particular though that the pkg_setup example ISN'T imo a good
idea -- rather, pkg-config should be used, as it will return the
appropriate --libs output whether ncurses is built with USE=tinfo
enabled or not.





signature.asc
Description: OpenPGP digital signature