Re: Unable to build mysql55-client NetBSD 8_Stable (Open SSL 1.1.1 related?)

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Jan 19,  5:09pm, Greg Troxel wrote:
} yancm%sdf.org@localhost writes:
} 
} >> yancm%sdf.org@localhost writes:
} >>
} >>> I updated pkgsrc to current this AM (Jan 18, 2020) and saw
} >>> OpenSSL had been updated... Running NetBSD 8_Stable
} >>> (Mid-December 2019 sources) amd_64
} >>
} >> Not only was openssl updated, but API_DEPENDS is set to 1.1, so while
} >> building things from pkgsrc used to use base system openssl on NetBSD,
} >> now they won't.
} >
} > For pkgsrc builds, I have
} > PREFER_PKGSRC+=openssl
} > in /etc/mk.conf
} >
} >> I see the point that 1.0 is no longer maintained, but I wonder if users
} >> should be able to ask for system openssl use or not.  I suspect that the
} >> number of issues is not that high and that fixing them is for the best.
} >
} > I assume this is directed at others as I do not have the skills to fix
} > packages really...?
} 
} Indeed it was.
} 
} >> I don't know if it would suffice to enable deprecated features.
} >
} > Is this something you suggest *I* do? If so, how?
} 
} There is a general pattern in libraries where
} 
}   a feature is announced as deprecated, and everyone ignores this
} 
}   a feature is marked to be unavailable, unless you define
}   WANT_DEPRECATED_FOO, and people grumble and define it
} 
}   finally the feature is removed, and people grumble much louder and
}   change the code, and people deciding whether to update the package in
}   packaging systems are in a bind
} 
} So I was wondering if we are in case 2 and if adding some sort of -D to
} the CFLAGS would help.
} 
} >> I wonder if you have tried 56 and 57.  There appear to be continuation
} >> forks of mysql as well, and my fuzzy impression is that there is gulf
} >> between the open source continuation fork world and the oracle world.
} >
} > mysql55 is a dependency of another package or packages, I am not pulling this
} > in explicitly. As my update has already deleted mysql55-client, I cannot
} > immediately
} > tell which package(s) depend on it.

     You can add

MYSQL_VERSION_DEFAULT=<here specify 56 or 57>

to your /etc/mk.conf.

As a sidenote, we should probably bump the default in
/usr/pkgsrc/mk/mysql.buildlink3.mk .  I suggest bumping it to 57
since that gives us more than 3.5 years without adding the surprises
that may come from a major new release series.

} There are two issues here:
} 
}   if 56 or 57 does build with new openssl, that's interesting
} 
}   it may be easier to migrate from 55 to 57 than to fix 55.  (I don't
}   know if there are good reasons for anyone/anything to be using 55.)
} 
} > These actions seem possible for package maintainers, but I'm just trying to
} > update locally installed packages against pkgsrc-current and failing...
} > Yes I understand the risks of following current, not complaining really,
} > but informing the tree seems broken at the moment. I pulled in changes
} > from yesterday and mysql55-client build is still broken per above.
} 
} I'll inquire.  But I'm afraid we may be arriving at "this software is
} EOL and has no functioning upstrea".

     I'm having trouble finding a good link for a document, but
these are the dates I found:

5.5 eol: Dec. 3rd, 2018
5.6 eol: Feb. 5th, 2021
5.7 eol: Oct. 21st, 2023
8.0 eol: April 2026

Note that 6.x and 7.x major release numbers were skipped.

So, 5.5 has been eol for more than a year, and 5.6 has just over a year
to go.

}-- End of excerpt from Greg Troxel