search

besser82 / libxcrypt

Extended crypt library for descrypt, md5crypt, bcrypt, and others
GNU Lesser General Public License v2.1
189 stars 52 forks source link

libcrypt.minver: Mark LoongArch as free of legacy ABIs #154

Closed xen0n closed 1 year ago

xen0n commented 2 years ago

This architecture is new, so there is no existing binaries to consider legacy compatibility for.

zhangn1985 commented 1 year ago

please consider debian, it still uses legacy API.

thesamesam commented 1 year ago

please consider debian, it still uses legacy API.

Debian started enabling the legacy API unnecessarily for an arch where no legacy binaries existed? Why?

xen0n commented 1 year ago

please consider debian, it still uses legacy API.

Debian upstream doesn't support LoongArch yet, so you actually have the chance to do the right thing and just get rid of the "compat" stuff, after all the LoongArch glibc port arrived after the crypt support in glibc was deprecated.

We especially can't do anything as long as your "debian" work isn't public.

Oh, and you actually don't get "compatibility" at all. AFAIK the Debian-derivative Loongnix makes use of the legacy ABI you mentioned, but it is old world as well, meaning you and other devs have to rebuild everything for the eventual upstream Debian anyway so the ABI "break" here isn't worrisome at all.

besser82 commented 1 year ago

@xen0n, thank you for your contribution!

This looks wrong to me, as LoongArch LP64 is well supported by glibc 2.36 and its yet not officially deprecated libcrypt.

besser82 commented 1 year ago

This issue has been addressed with release v4.4.29.

xen0n commented 1 year ago

@xen0n, thank you for your contribution!

This looks wrong to me, as LoongArch LP64 is well supported by glibc 2.36 and its yet not officially deprecated libcrypt.

This is a bit unfortunate, admittedly I didn't watch as closely as I'd want to when they upstreamed the glibc port, assuming the glibc libcrypt implementation was universally deprecated long ago. And it's still the case that no LoongArch distribution exists where libcrypt.so.1 usage cannot be removed without significant breakage; on the contrary the Gentoo loong port has completely eliminated it. So, marking the compat symbol version as GLIBC_2.36 actually breaks Gentoo, and IMO we should instead deprecate the glibc libcrypt for LoongArch ASAP and make the few Loongson-maintained distros follow suit. After all, there are very few new world users compared to other more mature arches, and the Loongson distros enabling the glibc libcrypt are AFAIK not fully open-source so we can't meaningfully support them anyway.