More things from other distros (Re: Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others)
On Wed, 18 Jul 2018 13:35:42 +0200 "Marco d'Itri" wrote: > I intend to package the new version of libxcrypt, which will replace the > orphaned libxcrypt source package. > > Some day it may replace crypt(3), currently provided by glibc: > https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt Great. And we can learn more improvements from other distributions, IMO, so I've done for Linux kernel config (https://bugs.debian.org/898629) curl https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897950 and time https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881429, maybe more... -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Re: Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others
On Sat, Jul 21, 2018 at 02:35:59AM +0100, Ben Hutchings wrote: I think you can do something like: [...] # postinst time: use link & rename to replace working version atomically. It's technically possible, but AFAICT a policy violation. Mike Stone
Re: Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others
On Fri, 2018-07-20 at 15:12 +0200, Marco d'Itri wrote: > On Jul 20, Guillem Jover wrote: > > > > And this means that perl (a libcrypt dependency) would be broken between > > > 1 and 5 (or maybe 1 and 3): is this ever going to work? > > > > Given that this new package is going to replace a part of glibc, it > > will need to behave as if it was part of the pseudo-Essential package > > set. When it comes to the diversion that means it needs to be added > > *without* the rename, so that we always have the libcrypt.so.1 present. > > I am not sure about how this would work: can you point me to an example > package? > > > But otherwise why would it be broken? > > Because indeed when using dpkg-divert --rename the file would be missing > for some time. [...] I think you can do something like: # build time: install libraries in a subdirectory to avoid conflict make install libdir=/lib/$DEB_HOST_MULTIARCH/libxcrypt1 # postinst time: use link & rename to replace working version atomically. # $DEB_HOST_MULTIARCH actually needs to be substituted at build time. for src in /lib/$DEB_HOST_MULTIARCH/libxcrypto/libcrypt.so.*; do dst=/lib/$DEB_HOST_MULTIARCH/$(basename $src) dpkg-divert --package libxcrypt1 --add --divert $dst $dst.glibc ln $dst $dst.glibc ln $src $dst.xcrypto mv $dst.xcrypto $dst done # prerm time: just rename for src in /lib/$DEB_HOST_MULTIARCH/libxcrypto/libcrypt.so.*; do dst=/lib/$DEB_HOST_MULTIARCH/$(basename $src) dpkg-divert --package libxcrypt1 --remove --divert $dst $dst.glibc mv $dst.glibc $dst done Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. signature.asc Description: This is a digitally signed message part
Re: Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others
On Fri, Jul 20, 2018 at 10:47:02AM +0200, Marco d'Itri wrote: On Jul 20, Philipp Kern wrote: I think it's odd to say "here, I'm packaging up a replacement for your library, but I'm not going to coordinate with you" when we are preparing a (somewhat) coherent distribution, so I don't think that option should be discarded. (Unless you have a reasonable worry that you experiment will fail and hence don't want to bother people, I guess.) At this point it is not an experiment anymore since Fedora switched and removal from glibc is still planned for a future release. I just wanted to have something usable and working before starting to discuss a transition plan. For purely testing purposes you could rely on a local diversion. (Install as a different library name, divert libcrypt, symlink.) Or you just build the package with the final names and force the conflicts. But the usable and working version demands a coordinated libc package. Mike Stone
Re: Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others
On Fri, Jul 20, 2018 at 02:18:51AM +0200, Marco d'Itri wrote: On Jul 18, Marco d'Itri wrote: Some day it may replace crypt(3), currently provided by glibc: https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt I tried creating a package which would divert libc's libcrypt, but it appears to be much harder than I thought. Installing it would looke like: 1) libcrypt1.preinst diverts glibc's libcrypt.so.1 2) dpkg does things 3) dpkg installs libxcrypt's libcrypt.so.1 4) dpkg does more things 5) libcrypt1.postinst runs/triggers ldconfig And this means that perl (a libcrypt dependency) would be broken between 1 and 5 (or maybe 1 and 3): is this ever going to work? But even if this worked correctly, glibc installs a libcrypt-N.NN.so, whose exact name I expect changes among different releases. Is there any way to implement all this safely? Remove libcrypt from glibc first, with a dependency on a libxcrypt that replaces it. I don't think it's safe to try as a diversion. You could maybe have fun with symlinks (see the /bin/sh saga) if you wanted to be able to switch back and forth, but if libcrypt is really leaving glibc there wouldn't seem to be any point to that. Mike Stone
Re: Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others
On Jul 20, Guillem Jover wrote: > > And this means that perl (a libcrypt dependency) would be broken between > > 1 and 5 (or maybe 1 and 3): is this ever going to work? > > Given that this new package is going to replace a part of glibc, it > will need to behave as if it was part of the pseudo-Essential package > set. When it comes to the diversion that means it needs to be added > *without* the rename, so that we always have the libcrypt.so.1 present. I am not sure about how this would work: can you point me to an example package? > But otherwise why would it be broken? Because indeed when using dpkg-divert --rename the file would be missing for some time. > > But even if this worked correctly, glibc installs a libcrypt-N.NN.so, > > whose exact name I expect changes among different releases. > This one is tied to the major.minor glibc version, so I think you > should just ignore it. I'd expect at most glibc itself to perhaps rely > on it, anything else using it would not be very sane IMO. I just feared ldconfig deciding to change the .so.1 symlink, I could not find any documentation about when it decides to change existing symlinks and then how it chooses between different versions of the same library. -- ciao, Marco signature.asc Description: PGP signature
Re: Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others
On Fri, 2018-07-20 at 02:18:51 +0200, Marco d'Itri wrote: > On Jul 18, Marco d'Itri wrote: > > Some day it may replace crypt(3), currently provided by glibc: > > https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt > I tried creating a package which would divert libc's libcrypt, but it > appears to be much harder than I thought. > > Installing it would looke like: > > 1) libcrypt1.preinst diverts glibc's libcrypt.so.1 > 2) dpkg does things > 3) dpkg installs libxcrypt's libcrypt.so.1 > 4) dpkg does more things > 5) libcrypt1.postinst runs/triggers ldconfig > > And this means that perl (a libcrypt dependency) would be broken between > 1 and 5 (or maybe 1 and 3): is this ever going to work? Given that this new package is going to replace a part of glibc, it will need to behave as if it was part of the pseudo-Essential package set. When it comes to the diversion that means it needs to be added *without* the rename, so that we always have the libcrypt.so.1 present. But otherwise why would it be broken? > But even if this worked correctly, glibc installs a libcrypt-N.NN.so, > whose exact name I expect changes among different releases. This one is tied to the major.minor glibc version, so I think you should just ignore it. I'd expect at most glibc itself to perhaps rely on it, anything else using it would not be very sane IMO. Thanks, Guillem
Re: Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others
On Jul 20, Philipp Kern wrote: > I think it's odd to say "here, I'm packaging up a replacement for your > library, but I'm not going to coordinate with you" when we are preparing > a (somewhat) coherent distribution, so I don't think that option should > be discarded. (Unless you have a reasonable worry that you experiment > will fail and hence don't want to bother people, I guess.) At this point it is not an experiment anymore since Fedora switched and removal from glibc is still planned for a future release. I just wanted to have something usable and working before starting to discuss a transition plan. -- ciao, Marco signature.asc Description: PGP signature
Re: Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others
On 20.07.2018 10:18, Marco d'Itri wrote: > On Jul 20, Philipp Kern wrote: >> Make sure that glibc splits out libcrypt into its own package, have libc6 >> depend on it and then provide libcrypt1? (Because it's really providing >> libcrypt's ABI from another package.) Versioning might be tricky, though. > At some point glibc will just stop building libcrypt, I am looking for > an interim solution that will not require coordination with the glibc > maintainers. I think it's odd to say "here, I'm packaging up a replacement for your library, but I'm not going to coordinate with you" when we are preparing a (somewhat) coherent distribution, so I don't think that option should be discarded. (Unless you have a reasonable worry that you experiment will fail and hence don't want to bother people, I guess.) Kind regards Philipp Kern
Re: Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others
On Jul 20, Philipp Kern wrote: > Make sure that glibc splits out libcrypt into its own package, have libc6 > depend on it and then provide libcrypt1? (Because it's really providing > libcrypt's ABI from another package.) Versioning might be tricky, though. At some point glibc will just stop building libcrypt, I am looking for an interim solution that will not require coordination with the glibc maintainers. -- ciao, Marco signature.asc Description: PGP signature
Re: Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others
On 2018-07-20 02:18, Marco d'Itri wrote: On Jul 18, Marco d'Itri wrote: Some day it may replace crypt(3), currently provided by glibc: https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt I tried creating a package which would divert libc's libcrypt, but it appears to be much harder than I thought. Installing it would looke like: 1) libcrypt1.preinst diverts glibc's libcrypt.so.1 2) dpkg does things 3) dpkg installs libxcrypt's libcrypt.so.1 4) dpkg does more things 5) libcrypt1.postinst runs/triggers ldconfig And this means that perl (a libcrypt dependency) would be broken between 1 and 5 (or maybe 1 and 3): is this ever going to work? But even if this worked correctly, glibc installs a libcrypt-N.NN.so, whose exact name I expect changes among different releases. Is there any way to implement all this safely? Make sure that glibc splits out libcrypt into its own package, have libc6 depend on it and then provide libcrypt1? (Because it's really providing libcrypt's ABI from another package.) Versioning might be tricky, though. Kind regards Philipp Kern
Re: Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others
On Jul 18, Marco d'Itri wrote: > Some day it may replace crypt(3), currently provided by glibc: > https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt I tried creating a package which would divert libc's libcrypt, but it appears to be much harder than I thought. Installing it would looke like: 1) libcrypt1.preinst diverts glibc's libcrypt.so.1 2) dpkg does things 3) dpkg installs libxcrypt's libcrypt.so.1 4) dpkg does more things 5) libcrypt1.postinst runs/triggers ldconfig And this means that perl (a libcrypt dependency) would be broken between 1 and 5 (or maybe 1 and 3): is this ever going to work? But even if this worked correctly, glibc installs a libcrypt-N.NN.so, whose exact name I expect changes among different releases. Is there any way to implement all this safely? -- ciao, Marco signature.asc Description: PGP signature
