[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Unable to build mysql55-client NetBSD 8_Stable (Open SSL 1.1.1 related?)
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
}-- End of excerpt from Greg Troxel
Main Index |
Thread Index |