Bug#961159: lib32{,x}gcc-s1: please provide lib{,x}32gcc1 (= 1:${binary:Version})
On Thu, Aug 13, 2020 at 12:26:53PM +0200, Bill Allombert wrote: > Building such i386 chroots now would require heavy use of snaphots.debian.org, > and would be much less convenient. > > > Also there are amd64 -> > > i386 cross compilers for the newer versions. Is it really necessary to > > keep the > > non-default multilib builds? > > What is the cost of adding this Provides ? I am sorry to have answered your question by a question, but it seems you are seeing downsides to adding the Provides we are not aware of. Cheers, -- Bill. Imagine a large red swirl here.
Bug#961159: lib32{,x}gcc-s1: please provide lib{,x}32gcc1 (= 1:${binary:Version})
On Thu, Aug 13, 2020 at 12:02:50PM +0200, Matthias Klose wrote: > On 8/13/20 11:49 AM, Bill Allombert wrote: > > On Thu, Aug 13, 2020 at 11:25:21AM +0200, Matthias Klose wrote: > >> On 8/12/20 11:16 PM, Bill Allombert wrote: > >>> On Thu, May 21, 2020 at 02:15:51PM +0200, Andreas Beckmann wrote: > On 21/05/2020 14.05, Matthias Klose wrote: > > On 5/20/20 10:32 PM, Andreas Beckmann wrote: > >> With the transitional packages gone in 10.1.0-2, please add versioned > >> (epoched!) provides on the old names (as already done in libgcc-s1) > >> in order to keep old packages installable along the latest gcc. > > > > I'd like to avoid that. Please build the nvidia packages using the new > > package > > names. > > This has nothing to do with nvidia. This breaks keeping old compilers > around, which so far worked fine for a long time. > >>> > >>> Seconded. I have all versions of gcc starting at 4.4 that I would like > >>> to keep, but the upgrade require to remove them. > >> > >> I don't want to do that. What exactly depends on the non-default multilib > >> libraries? > > > > # apt-get dist-upgrade > > The following packages will be REMOVED: > > g++-4.4-multilib g++-4.5-multilib g++-4.6-multilib g++-4.7-multilib > > g++-5-multilib > > g++-6-multilib gcc-4.4-multilib gcc-4.5-multilib gcc-4.6-multilib > > gcc-4.7-multilib > > gcc-5-multilib gcc-6-multilib lib32asan0 lib32asan1 lib32asan2 lib32asan3 > > lib32asan4 > > lib32cilkrts5 lib32gcc-4.7-dev lib32gcc-4.8-dev lib32gcc-4.9-dev > > lib32gcc-5-dev > > lib32gcc-6-dev lib32gcc-7-dev lib32gcc1 lib32stdc++-4.9-dev > > lib32stdc++-5-dev > > lib32stdc++-6-dev lib32stdc++6-4.7-dev lib32ubsan0 > > libclang-common-5.0-dev libgc1c2 libgcc1 > > libx32asan0 libx32asan1 libx32asan2 libx32asan3 libx32asan4 > > libx32cilkrts5 libx32gcc-4.7-dev > > libx32gcc-5-dev libx32gcc-6-dev libx32gcc-7-dev libx32gcc1 > > libx32stdc++-5-dev > > libx32stdc++-6-dev libx32stdc++6-4.7-dev libx32ubsan0 > > ok, so this is for the multilib compiler packages only. The default multilib > is > not affected by this change. > > > libgcc-s1 Provides: libgcc1 (= 1:10-20200418-1) which is OK. > > However lib32gcc-s1 does not provides lib32gcc1 (= 1:10-20200418-1) > > so packages depending on lib32gcc1 are broken. > > > > I like to add: I have all these compilers available for test purpose > > on my system thanks to your hard work packaging gcc over so many years. > > It is really neat. It would be sad to lose all this now. > > You have those available in i386/x32 chroots as well. Building such i386 chroots now would require heavy use of snaphots.debian.org, and would be much less convenient. > Also there are amd64 -> > i386 cross compilers for the newer versions. Is it really necessary to keep > the > non-default multilib builds? What is the cost of adding this Provides ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#961159: lib32{,x}gcc-s1: please provide lib{,x}32gcc1 (= 1:${binary:Version})
I have a similar usecase like Bill: I have lots of gcc-*-multilib packages installed (from ancient to to experimental) for doing compilation tests for $software with many different compiler versions. nearly all lib(x)32XYZ packages built by gcc-N (N < 9? 8?) depend on lib(x)32gcc1 In the end I worked around it with equivs: ### Commented entries have reasonable defaults. ### Uncomment to edit them. # Source: Section: misc Priority: optional # Homepage: Standards-Version: 3.9.2 Package: lib32gcc1 Architecture: amd64 Version: 1:10.1.0-1 Depends: lib32gcc-s1 (>= 10.1.0-1) Description: GCC support library (dependency package, 32bit) This is a dependency package, and can be safely removed after upgrade. Homepage: http://gcc.gnu.org/ ### Commented entries have reasonable defaults. ### Uncomment to edit them. # Source: Section: misc Priority: optional # Homepage: Standards-Version: 3.9.2 Package: libx32gcc1 Architecture: amd64 Version: 1:10.1.0-1 Depends: libx32gcc-s1 (>= 10.1.0-1) Description: GCC support library (x32) This is a dependency package, and can be safely removed after upgrade. Homepage: http://gcc.gnu.org/ Andreas
Bug#961159: lib32{,x}gcc-s1: please provide lib{,x}32gcc1 (= 1:${binary:Version})
On 8/13/20 11:49 AM, Bill Allombert wrote: > On Thu, Aug 13, 2020 at 11:25:21AM +0200, Matthias Klose wrote: >> On 8/12/20 11:16 PM, Bill Allombert wrote: >>> On Thu, May 21, 2020 at 02:15:51PM +0200, Andreas Beckmann wrote: On 21/05/2020 14.05, Matthias Klose wrote: > On 5/20/20 10:32 PM, Andreas Beckmann wrote: >> With the transitional packages gone in 10.1.0-2, please add versioned >> (epoched!) provides on the old names (as already done in libgcc-s1) >> in order to keep old packages installable along the latest gcc. > > I'd like to avoid that. Please build the nvidia packages using the new > package > names. This has nothing to do with nvidia. This breaks keeping old compilers around, which so far worked fine for a long time. >>> >>> Seconded. I have all versions of gcc starting at 4.4 that I would like >>> to keep, but the upgrade require to remove them. >> >> I don't want to do that. What exactly depends on the non-default multilib >> libraries? > > # apt-get dist-upgrade > The following packages will be REMOVED: > g++-4.4-multilib g++-4.5-multilib g++-4.6-multilib g++-4.7-multilib > g++-5-multilib > g++-6-multilib gcc-4.4-multilib gcc-4.5-multilib gcc-4.6-multilib > gcc-4.7-multilib > gcc-5-multilib gcc-6-multilib lib32asan0 lib32asan1 lib32asan2 lib32asan3 > lib32asan4 > lib32cilkrts5 lib32gcc-4.7-dev lib32gcc-4.8-dev lib32gcc-4.9-dev > lib32gcc-5-dev > lib32gcc-6-dev lib32gcc-7-dev lib32gcc1 lib32stdc++-4.9-dev > lib32stdc++-5-dev > lib32stdc++-6-dev lib32stdc++6-4.7-dev lib32ubsan0 > libclang-common-5.0-dev libgc1c2 libgcc1 > libx32asan0 libx32asan1 libx32asan2 libx32asan3 libx32asan4 > libx32cilkrts5 libx32gcc-4.7-dev > libx32gcc-5-dev libx32gcc-6-dev libx32gcc-7-dev libx32gcc1 > libx32stdc++-5-dev > libx32stdc++-6-dev libx32stdc++6-4.7-dev libx32ubsan0 ok, so this is for the multilib compiler packages only. The default multilib is not affected by this change. > libgcc-s1 Provides: libgcc1 (= 1:10-20200418-1) which is OK. > However lib32gcc-s1 does not provides lib32gcc1 (= 1:10-20200418-1) > so packages depending on lib32gcc1 are broken. > > I like to add: I have all these compilers available for test purpose > on my system thanks to your hard work packaging gcc over so many years. > It is really neat. It would be sad to lose all this now. You have those available in i386/x32 chroots as well. Also there are amd64 -> i386 cross compilers for the newer versions. Is it really necessary to keep the non-default multilib builds? Matthias
Bug#961159: lib32{,x}gcc-s1: please provide lib{,x}32gcc1 (= 1:${binary:Version})
On Thu, Aug 13, 2020 at 11:25:21AM +0200, Matthias Klose wrote: > On 8/12/20 11:16 PM, Bill Allombert wrote: > > On Thu, May 21, 2020 at 02:15:51PM +0200, Andreas Beckmann wrote: > >> On 21/05/2020 14.05, Matthias Klose wrote: > >>> On 5/20/20 10:32 PM, Andreas Beckmann wrote: > With the transitional packages gone in 10.1.0-2, please add versioned > (epoched!) provides on the old names (as already done in libgcc-s1) > in order to keep old packages installable along the latest gcc. > >>> > >>> I'd like to avoid that. Please build the nvidia packages using the new > >>> package > >>> names. > >> > >> This has nothing to do with nvidia. This breaks keeping old compilers > >> around, which so far worked fine for a long time. > > > > Seconded. I have all versions of gcc starting at 4.4 that I would like > > to keep, but the upgrade require to remove them. > > I don't want to do that. What exactly depends on the non-default multilib > libraries? # apt-get dist-upgrade The following packages will be REMOVED: g++-4.4-multilib g++-4.5-multilib g++-4.6-multilib g++-4.7-multilib g++-5-multilib g++-6-multilib gcc-4.4-multilib gcc-4.5-multilib gcc-4.6-multilib gcc-4.7-multilib gcc-5-multilib gcc-6-multilib lib32asan0 lib32asan1 lib32asan2 lib32asan3 lib32asan4 lib32cilkrts5 lib32gcc-4.7-dev lib32gcc-4.8-dev lib32gcc-4.9-dev lib32gcc-5-dev lib32gcc-6-dev lib32gcc-7-dev lib32gcc1 lib32stdc++-4.9-dev lib32stdc++-5-dev lib32stdc++-6-dev lib32stdc++6-4.7-dev lib32ubsan0 libclang-common-5.0-dev libgc1c2 libgcc1 libx32asan0 libx32asan1 libx32asan2 libx32asan3 libx32asan4 libx32cilkrts5 libx32gcc-4.7-dev libx32gcc-5-dev libx32gcc-6-dev libx32gcc-7-dev libx32gcc1 libx32stdc++-5-dev libx32stdc++-6-dev libx32stdc++6-4.7-dev libx32ubsan0 libgcc-s1 Provides: libgcc1 (= 1:10-20200418-1) which is OK. However lib32gcc-s1 does not provides lib32gcc1 (= 1:10-20200418-1) so packages depending on lib32gcc1 are broken. I like to add: I have all these compilers available for test purpose on my system thanks to your hard work packaging gcc over so many years. It is really neat. It would be sad to lose all this now. Cheers, -- Bill. Imagine a large red swirl here.
Bug#961159: lib32{,x}gcc-s1: please provide lib{,x}32gcc1 (= 1:${binary:Version})
On 8/12/20 11:16 PM, Bill Allombert wrote: > On Thu, May 21, 2020 at 02:15:51PM +0200, Andreas Beckmann wrote: >> On 21/05/2020 14.05, Matthias Klose wrote: >>> On 5/20/20 10:32 PM, Andreas Beckmann wrote: With the transitional packages gone in 10.1.0-2, please add versioned (epoched!) provides on the old names (as already done in libgcc-s1) in order to keep old packages installable along the latest gcc. >>> >>> I'd like to avoid that. Please build the nvidia packages using the new >>> package >>> names. >> >> This has nothing to do with nvidia. This breaks keeping old compilers >> around, which so far worked fine for a long time. > > Seconded. I have all versions of gcc starting at 4.4 that I would like > to keep, but the upgrade require to remove them. I don't want to do that. What exactly depends on the non-default multilib libraries?
Bug#961159: lib32{,x}gcc-s1: please provide lib{,x}32gcc1 (= 1:${binary:Version})
On Thu, May 21, 2020 at 02:15:51PM +0200, Andreas Beckmann wrote: > On 21/05/2020 14.05, Matthias Klose wrote: > > On 5/20/20 10:32 PM, Andreas Beckmann wrote: > >> With the transitional packages gone in 10.1.0-2, please add versioned > >> (epoched!) provides on the old names (as already done in libgcc-s1) > >> in order to keep old packages installable along the latest gcc. > > > > I'd like to avoid that. Please build the nvidia packages using the new > > package > > names. > > This has nothing to do with nvidia. This breaks keeping old compilers > around, which so far worked fine for a long time. Seconded. I have all versions of gcc starting at 4.4 that I would like to keep, but the upgrade require to remove them. Cheers, -- Bill. Imagine a large red swirl here.
Bug#961159: lib32{,x}gcc-s1: please provide lib{,x}32gcc1 (= 1:${binary:Version})
On 21/05/2020 14.05, Matthias Klose wrote: > On 5/20/20 10:32 PM, Andreas Beckmann wrote: >> With the transitional packages gone in 10.1.0-2, please add versioned >> (epoched!) provides on the old names (as already done in libgcc-s1) >> in order to keep old packages installable along the latest gcc. > > I'd like to avoid that. Please build the nvidia packages using the new > package > names. This has nothing to do with nvidia. This breaks keeping old compilers around, which so far worked fine for a long time. Andreas
Bug#961159: lib32{,x}gcc-s1: please provide lib{,x}32gcc1 (= 1:${binary:Version})
On 5/20/20 10:32 PM, Andreas Beckmann wrote: > Package: lib32gcc-s1,libx32gcc-s1 > Version: 10.1.0-2 > Severity: important > > With the transitional packages gone in 10.1.0-2, please add versioned > (epoched!) provides on the old names (as already done in libgcc-s1) > in order to keep old packages installable along the latest gcc. I'd like to avoid that. Please build the nvidia packages using the new package names.
Bug#961159: lib32{,x}gcc-s1: please provide lib{,x}32gcc1 (= 1:${binary:Version})
Package: lib32gcc-s1,libx32gcc-s1 Version: 10.1.0-2 Severity: important With the transitional packages gone in 10.1.0-2, please add versioned (epoched!) provides on the old names (as already done in libgcc-s1) in order to keep old packages installable along the latest gcc. Thanks Andreas
