public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: konsolebox <konsolebox@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] tinfo flag
Date: Wed, 7 Dec 2016 16:16:45 +0800	[thread overview]
Message-ID: <CAJnmqwYY_rtGosQeoiUC0A=2fEarO=SHg4Kxp9azNLOd7LDVxg@mail.gmail.com> (raw)
In-Reply-To: <20161207062334.790215a2.mgorny@gentoo.org>

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

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


  reply	other threads:[~2016-12-07  8:17 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-05 11:13 [gentoo-dev] tinfo flag konsolebox
2016-12-06 17:12 ` Ian Stakenvicius
2016-12-06 18:01   ` konsolebox
2016-12-06 17:54 ` Mike Gilbert
2016-12-06 18:05   ` konsolebox
2016-12-06 18:17     ` Mike Gilbert
2016-12-06 19:03       ` konsolebox
2016-12-06 21:15   ` Michał Górny
2016-12-06 22:26     ` Mike Gilbert
2016-12-07  2:11       ` William Hubbs
2016-12-07  2:44         ` Mike Gilbert
2016-12-07  7:10           ` Daniel Campbell
2016-12-07  5:23         ` Michał Górny
2016-12-07  8:16           ` konsolebox [this message]
2016-12-07  9:16             ` Michał Górny
2016-12-07 10:40               ` konsolebox
2016-12-07 15:27                 ` Ian Stakenvicius
2016-12-07 18:13                   ` Pacho Ramos
2016-12-11 10:58                   ` Daniel Campbell
2016-12-07 17:19               ` Alexis Ballier
2016-12-07  8:08       ` konsolebox
2016-12-07 12:58     ` Pacho Ramos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJnmqwYY_rtGosQeoiUC0A=2fEarO=SHg4Kxp9azNLOd7LDVxg@mail.gmail.com' \
    --to=konsolebox@gmail.com \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox