On 07/12/16 05:40 AM, konsolebox wrote: > On Wed, Dec 7, 2016 at 5:16 PM, Michał Górny <[email protected]> wrote: >> On Wed, 7 Dec 2016 16:16:45 +0800 >> konsolebox <[email protected]> wrote: >> >>> On Wed, Dec 7, 2016 at 1:23 PM, Michał Górny <[email protected]> wrote: >>>> On Tue, 6 Dec 2016 20:11:34 -0600 >>>> William Hubbs <[email protected]> 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 <[email protected]> wrote: >>>>>>> On Tue, 6 Dec 2016 12:54:26 -0500 >>>>>>> Mike Gilbert <[email protected]> wrote: >>>>>>> >>>>>>>> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox <[email protected]> >>>>>>>> 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.
signature.asc
Description: OpenPGP digital signature
