[recreating response since I wasn't CC'd] On 11/25/2016, Joerg wrote:
On Fri, Nov 25, 2016 at 08:56:39AM -0600, John Marino wrote:On 11/25/2016 07:19, Joerg Sonnenberger wrote: > On Thu, Nov 24, 2016 at 05:54:07PM -0600, John Marino wrote: > > On 11/24/2016 17:46, Joerg Sonnenberger wrote: > > > On Thu, Nov 24, 2016 at 11:35:19PM +0000, John Marino wrote: > > > > There is no termcap library available in any form on DragonFly. > > > > Discussed with wiz@. > > > > > > But termcap.b3.mk already has fallback logic to curses, so that should > > > be used. > > > > > > > Please note 2 things: > > 1) the other line "CONFIGURE_ARGS+= --with-curses=yes" > > That doesn't invalidate anything I said. It still requires a conditional statement to handle this configure argument. Unless you have OPSYS-specific configure arguments such as CONFIGURE_ARGS_DragonFly= --with-curses=yes Once the condition is required, then changing the include is in the noise.Except the hard-coding OS part and that it works against ncurses on many other systems already. Even then, the correct way if it was really necessary would be to check the termcap implemenation type and only then add --with-curses=yes as necessary.
A) That implies believing that building it with termcap and falling back to ncurses is more correct than building with ncurses and falling to termcap. B) That requires changing several things, all out of scope of this, and requiring having to take point to fix all of them and get approval.
wiz advised to push the fix. I was holding back because of exactly this dynamic.
> > 2) none of the curses / termcap logic works on DragonFly, at all. > > > > For many months, curses library is private but the headers were public. > > Since pkgsrc doesn't actually test ability to link but only assumes that > > header presence == library presence, it's all broken. > > Ah, so DragonFly provides a brain dead installation and everything else > should cope. I understand. wow, do you choose to be this way or can you simply not help it? Pkgsrc *claims* to support DragonFly. This claim is rather dubious because it's been broken for well over a year. You've been party to related PRs and didn't lift a finger.Right, my interest is limited. Given the current situation, I would prefer to drop any such claims than continue to add more and more hacks.
I was unaware that you have the authority to do this. If so, as long as you
A) remove claims of every platform isn't practically supported and B) you specifically claim it's no longer supported I am fine with this approach
If pkgsrc can't utilize readline on a platform, then in effect it doesn't support that platform. The same goes for curses and openssl.That's bullshit. It works perfectly well on a lot of platforms in various mixes of installations.
No, it's not bullshit. If the readline port cannot be built, a critical portion of the tree is broken. A big enough portion to invalidate any claim of support. When you add curses and openssl to it, it only makes the situation that much worse.
The status of other platforms is irrelevant. The fact is that as devel/readline was, it didn't build on DF.
nor does gettext (another major port) without another infrastructure patch involving libtool which illustrates another deeper problem.
This wouldn't be necessary if it wasn't for pkgsrc's BRAIN DEAD test procedures that fail to test at least for the presence of the library yourself.The same type of checks is present in a lot of packages and likely the reasons for a lot of the problems you see. There is no sane reason for providing headers in an accessible place when not providing the libraries. Zero. It is basically begging for problems.
And far more packages actually test it properly, what's your point? There was no practical issue other than pkgsrc. These headers are no longer there, but they were for many months, including the current release.
None of that changes the fact that the assumptions used by pkgsrc are demonstrably bad and easily fixable. Yet you continue with the approach of "if it works for me, it's fine".
As you said, if you remove claims of platform support and limit it to netbsd and smartos, it does resolve most of this. It's just that for years pkgsrc has been proclaiming this universality that it appears you're not eager to actually maintain.
John --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus