Bug#961159: lib32{,x}gcc-s1: please provide lib{,x}32gcc1 (= 1:${binary:Version})

2020-08-13 Thread Bill Allombert
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})

2020-08-13 Thread Andreas Beckmann
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})

2020-08-13 Thread Matthias Klose
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})

2020-08-13 Thread Bill Allombert
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})

2020-08-13 Thread Matthias Klose
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})

2020-08-12 Thread Bill Allombert
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})

2020-05-21 Thread Andreas Beckmann
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})

2020-05-21 Thread Matthias Klose
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})

2020-05-20 Thread Andreas Beckmann
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