Bug#941853: crypt(3) should be provided by libxcrypt
On Oct 07, Aurelien Jarno wrote: Dear debian-boot: for the benefit of the ftpmasters, please confirm that you have no objections to src:libxcrypt generating a libcrypt1-udeb package (initially in experimental) which will provide crypt(3) currently in the libc udeb. > I guess we should keep building libcrypt1 for the bi/tri-arch packages. What do I need to do about this? > > (Also, do not forget about the man pages in the -dev packages.) > The man page was not provided by the -dev package but by manpages-dev. Actually I see that it automatically stopped shipping crypt(3) and crypt_r(3) in 5.01-1, so I will add Breaks+Replaces. > We must build the libcrypt1 udeb, and add a depends from libc6-deb to > libcrypt1-udeb, otherwise we might break d-i. At some point we might OK, I will start again building the udeb with the next upload. -- ciao, Marco signature.asc Description: PGP signature
Bug#941853: crypt(3) should be provided by libxcrypt
On 2019-10-07 00:00, Marco d'Itri wrote: > On Oct 06, Aurelien Jarno wrote: > > > Ah this doesn't match the version in unstable, it's only in NEW for now. > > I guess we need to wait for it to get out of there first. > For reasons which I do not understand, the ftpmasters obliquely let me > know that they will not accept libxcrypt from NEW until the libc > maintainers will explicitly confirm that we have agreed on a plan to use > it. Do you mind confirming this? AFAIK, the glibc team have never been asked about that. For the ftpmasters: I confirm we'll replace libcrypt.so.1 from libc6 by the one from libxcrypt. Therefore please accept the package. > > > So I think that libc6 should have Depends/Replaces on libcrypt1. > > Agreed for the Depends. I don't get why it needs a Replaces. On the > > other hand libcrypt1 needs a Replaces: libc6, libc6.1, libc0.1, libc0.3 > > with the correct version. > Yes, this is what I meant. So: > > Package: libcrypt1 > Breaks: libc6 (<< 2.29-X) > Replaces: libc6 (<< 2.29-X) > > Package: libcrypt1-dev > Breaks: libc6-dev (<< 2.29-X) > Replaces: libc6-dev (<< 2.29-X) > > Package: libc6 > Depends: libcrypt1 > > Package: libc6-dev > Depends: libcrypt1-dev > > And all the architecture-specific variations which I will figure out. This is libc0.1, libc0.3, libc6 and libc6.1 for the library package. This is libc0.1-dev, libc0.3-dev, libc6-dev and libc6.1-dev for the library packages. I guess we should keep building libcrypt1 for the bi/tri-arch packages. > (Also, do not forget about the man pages in the -dev packages.) The man page was not provided by the -dev package but by manpages-dev. > There is also a libcrypt1 udeb: do you prefer to start building it now > or deal with it later? We must build the libcrypt1 udeb, and add a depends from libc6-deb to libcrypt1-udeb, otherwise we might break d-i. At some point we might want to rebuild all udebs (at least by hand to detect the affected udebs) and drop that dependency. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#941853: crypt(3) should be provided by libxcrypt
On Oct 06, Aurelien Jarno wrote: > Ah this doesn't match the version in unstable, it's only in NEW for now. > I guess we need to wait for it to get out of there first. For reasons which I do not understand, the ftpmasters obliquely let me know that they will not accept libxcrypt from NEW until the libc maintainers will explicitly confirm that we have agreed on a plan to use it. Do you mind confirming this? > > So I think that libc6 should have Depends/Replaces on libcrypt1. > Agreed for the Depends. I don't get why it needs a Replaces. On the > other hand libcrypt1 needs a Replaces: libc6, libc6.1, libc0.1, libc0.3 > with the correct version. Yes, this is what I meant. So: Package: libcrypt1 Breaks: libc6 (<< 2.29-X) Replaces: libc6 (<< 2.29-X) Package: libcrypt1-dev Breaks: libc6-dev (<< 2.29-X) Replaces: libc6-dev (<< 2.29-X) Package: libc6 Depends: libcrypt1 Package: libc6-dev Depends: libcrypt1-dev And all the architecture-specific variations which I will figure out. (Also, do not forget about the man pages in the -dev packages.) There is also a libcrypt1 udeb: do you prefer to start building it now or deal with it later? -- ciao, Marco signature.asc Description: PGP signature
Bug#941853: crypt(3) should be provided by libxcrypt
On 2019-10-06 22:04, Marco d'Itri wrote: > On Oct 06, Aurelien Jarno wrote: > > > The libxcrypt implementation is indeed source backward compatible, > > however doesn't seem binary backward compatible. libc6 provides > > libcrypt.so.1 while libxcrypt provides libcrypt.so.2. > It provides both, but currently I am not even building libcrypt.so.2 > since I do not see the point. Ah this doesn't match the version in unstable, it's only in NEW for now. I guess we need to wait for it to get out of there first. > md@bongo:/USR3/src/P/libxcrypt$ dpkg-deb -c libcrypt1_4.4.8-1_amd64.deb > drwxr-xr-x root/root 0 2019-09-01 22:04 ./ > drwxr-xr-x root/root 0 2019-09-01 22:04 ./lib/ > drwxr-xr-x root/root 0 2019-09-01 22:04 ./lib/x86_64-linux-gnu/ > -rw-r--r-- root/root202680 2019-09-01 22:04 > ./lib/x86_64-linux-gnu/libcrypt.so.1.1.0 > drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/ > drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/share/ > drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/share/doc/ > drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/share/doc/libcrypt1/ > -rw-r--r-- root/root 6476 2019-09-01 21:03 > ./usr/share/doc/libcrypt1/NEWS.gz > -rw-r--r-- root/root 4052 2019-03-06 00:02 > ./usr/share/doc/libcrypt1/README.md.gz > -rw-r--r-- root/root 799 2019-09-01 22:04 > ./usr/share/doc/libcrypt1/changelog.Debian.gz > -rw-r--r-- root/root 5628 2019-09-01 22:04 > ./usr/share/doc/libcrypt1/copyright > lrwxrwxrwx root/root 0 2019-09-01 22:04 > ./lib/x86_64-linux-gnu/libcrypt.so.1 -> libcrypt.so.1.1.0 > lrwxrwxrwx root/root 0 2019-09-01 22:04 > ./usr/share/doc/libcrypt1/TODO -> TODO.md > > So I think that libc6 should have Depends/Replaces on libcrypt1. Agreed for the Depends. I don't get why it needs a Replaces. On the other hand libcrypt1 needs a Replaces: libc6, libc6.1, libc0.1, libc0.3 with the correct version. > I suggest that we make a pass in experimental to be sure to not leave > unstable uninstallable for days. Fine for me. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#941853: crypt(3) should be provided by libxcrypt
Hi, On 2019-10-06 17:55, Marco d'Itri wrote: > Package: glibc > Version: 2.29-2 > Severity: normal > > The libc implementation of crypt(3) has been deprecated since 2.28. > libxcrypt is needed to support modern hashing algorithms. > > How do you want to coordinate switching to libxcrypt? > > The libxcrypt implementation is source and binary backward compatible, > so no transitions are needed. I think that we only need to coordinate > Replaces/Depends. The libxcrypt implementation is indeed source backward compatible, however doesn't seem binary backward compatible. libc6 provides libcrypt.so.1 while libxcrypt provides libcrypt.so.2. It is therefore not possible to build glibc with --disable-crypt. I guess what we can do is to remove crypt.h, libcrypt.a and libcrypt.so from libc6-dev and add a depends on libcrypt2-dev to libc6-dev. On its side, libcrypt2-dev should break and replace libc6-dev with the right version. There should be no need to add a depends from libc6 to libcrypt2 as the two libraries have a different soname and thus are co-installable. If that sounds ok, I guess we can do that in the next glibc upload. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#941853: crypt(3) should be provided by libxcrypt
On Oct 06, Aurelien Jarno wrote: > The libxcrypt implementation is indeed source backward compatible, > however doesn't seem binary backward compatible. libc6 provides > libcrypt.so.1 while libxcrypt provides libcrypt.so.2. It provides both, but currently I am not even building libcrypt.so.2 since I do not see the point. md@bongo:/USR3/src/P/libxcrypt$ dpkg-deb -c libcrypt1_4.4.8-1_amd64.deb drwxr-xr-x root/root 0 2019-09-01 22:04 ./ drwxr-xr-x root/root 0 2019-09-01 22:04 ./lib/ drwxr-xr-x root/root 0 2019-09-01 22:04 ./lib/x86_64-linux-gnu/ -rw-r--r-- root/root202680 2019-09-01 22:04 ./lib/x86_64-linux-gnu/libcrypt.so.1.1.0 drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/ drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/share/ drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/share/doc/ drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/share/doc/libcrypt1/ -rw-r--r-- root/root 6476 2019-09-01 21:03 ./usr/share/doc/libcrypt1/NEWS.gz -rw-r--r-- root/root 4052 2019-03-06 00:02 ./usr/share/doc/libcrypt1/README.md.gz -rw-r--r-- root/root 799 2019-09-01 22:04 ./usr/share/doc/libcrypt1/changelog.Debian.gz -rw-r--r-- root/root 5628 2019-09-01 22:04 ./usr/share/doc/libcrypt1/copyright lrwxrwxrwx root/root 0 2019-09-01 22:04 ./lib/x86_64-linux-gnu/libcrypt.so.1 -> libcrypt.so.1.1.0 lrwxrwxrwx root/root 0 2019-09-01 22:04 ./usr/share/doc/libcrypt1/TODO -> TODO.md So I think that libc6 should have Depends/Replaces on libcrypt1. I suggest that we make a pass in experimental to be sure to not leave unstable uninstallable for days. -- ciao, Marco signature.asc Description: PGP signature
Bug#941853: crypt(3) should be provided by libxcrypt
Package: glibc Version: 2.29-2 Severity: normal The libc implementation of crypt(3) has been deprecated since 2.28. libxcrypt is needed to support modern hashing algorithms. How do you want to coordinate switching to libxcrypt? The libxcrypt implementation is source and binary backward compatible, so no transitions are needed. I think that we only need to coordinate Replaces/Depends. The libxcrypt package lives in https://salsa.debian.org/md/libxcrypt . It has been in Fedora since over one year: https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt -- ciao, Marco signature.asc Description: PGP signature
