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