Bug#855851: gcc-3.3: still in stretch

2017-02-23 Thread Philipp Kern

On 2017-02-23 09:49, Santiago Vila wrote:

Of course it's not word-by-word what I wrote, but it was clearly the
meaning: When we remove packages from the distribution because we
don't need them anymore, we don't just remove them from testing, we
remove them from both testing and unstable.

[...]

So what's the point in talking about the freeze in your previous
message? It's not too late to remove a whole compiler but it's too
late to remove a leaf package on which no other Debian package depends
for years?

I would really like to understand the logic of your reasoning, but I
still can't, sorry.


You are talking about stretch. The bug's title is stretch. You are 
talking about a removal from a frozen set of packages right after we 
have frozen. In your mind freezing is only to not allow new packages to 
go in. In my mind it's also freezing the set of packages to not 
arbitrarily remove them post-freeze. Especially if the reverse 
dependencies are outside of the archive and hence unknown.


Kind regards
Philipp Kern



Bug#855851: gcc-3.3: still in stretch

2017-02-23 Thread Santiago Vila
On Thu, Feb 23, 2017 at 09:02:23AM -0500, Philipp Kern wrote:
> On 2017-02-23 08:05, Santiago Vila wrote:
> > I was actually talking about every stable release from now on,
> > starting from stretch, so yes, it would if we wanted to remove the
> > package from both testing and unstable.
> 
> That's not what you wrote.

Of course it's not word-by-word what I wrote, but it was clearly the
meaning: When we remove packages from the distribution because we
don't need them anymore, we don't just remove them from testing, we
remove them from both testing and unstable.

Do you still need examples or references that this is what we usually do
in those cases? (Report against the package, reassign to ftp.debian.org).

> The package as-is is in no way unfit for stretch nor sid. Your reference to
> gcc-5 serves absolutely zero purpose here as this package does not build a
> compiler.

So what's the point in talking about the freeze in your previous
message? It's not too late to remove a whole compiler but it's too
late to remove a leaf package on which no other Debian package depends
for years?

I would really like to understand the logic of your reasoning, but I
still can't, sorry.

Thanks.



Bug#855851: gcc-3.3: still in stretch

2017-02-23 Thread Philipp Kern

On 2017-02-23 08:05, Santiago Vila wrote:

I was actually talking about every stable release from now on,
starting from stretch, so yes, it would if we wanted to remove the
package from both testing and unstable.


That's not what you wrote.


I don't understand why this is so much difficult to explain.


I think you come across as incredibly confrontational.

The package as-is is in no way unfit for stretch nor sid. Your reference 
to gcc-5 serves absolutely zero purpose here as this package does not 
build a compiler.


Kind regards
Philipp Kern



Bug#855851: gcc-3.3: still in stretch

2017-02-23 Thread Santiago Vila
On Thu, 23 Feb 2017, Philipp Kern wrote:

> On 2/22/2017 4:26 PM, Santiago Vila wrote:
> > On Wed, Feb 22, 2017 at 04:11:45PM +0100, Philipp Kern wrote:
> > 
> >> Why would I need to justify package presence in a serious RC bug?
> > 
> > No need, the idea was for this bug to be either reassigned to
> > ftp.debian.org (keeping the severity) or downgraded to serve as
> > documentation, but not both.
> 
> You are talking about stretch, not sid. So the bug would never have been
> reassigned to ftp.debian.org.

I was actually talking about every stable release from now on,
starting from stretch, so yes, it would if we wanted to remove the
package from both testing and unstable.

> Neither would the RC severity have really been appropriate.

It would. That's the right severity for "we don't want this package in the next
stable" and also for "do we really want this package in the next stable?".

Do you want me to find examples for this?
I don't understand why this is so much difficult to explain.

BTW: gcc-5 was removed on 2017-02-19, well after the freeze.

Thanks.



Bug#855851: gcc-3.3: still in stretch

2017-02-23 Thread Philipp Kern
On 2/22/2017 4:26 PM, Santiago Vila wrote:
> On Wed, Feb 22, 2017 at 04:11:45PM +0100, Philipp Kern wrote:
> 
>> Why would I need to justify package presence in a serious RC bug?
> 
> No need, the idea was for this bug to be either reassigned to
> ftp.debian.org (keeping the severity) or downgraded to serve as
> documentation, but not both.

You are talking about stretch, not sid. So the bug would never have been
reassigned to ftp.debian.org. Neither would the RC severity have really
been appropriate.

>> It only builds libstdc++5. It's not even a full compiler. That's for
>> compatibility with old binaries.
> 
> Ok. Do we have such old binaries in stretch? Are such old binaries
> still distributed outside Debian? If not, are there any other
> objective criteria which is supposed to be met before removing
> libstdc++5? Or we are keeping it just for inertia?

IBM binaries used to ship linked against libstdc++5. I don't think now
*after the freeze* is the time to remove it, even if it were just for
inertia.

Kind regards
Philipp Kern



Bug#855851: gcc-3.3: still in stretch

2017-02-22 Thread Santiago Vila
On Wed, Feb 22, 2017 at 04:11:45PM +0100, Philipp Kern wrote:

> Why would I need to justify package presence in a serious RC bug?

No need, the idea was for this bug to be either reassigned to
ftp.debian.org (keeping the severity) or downgraded to serve as
documentation, but not both.

> It only builds libstdc++5. It's not even a full compiler. That's for
> compatibility with old binaries.

Ok. Do we have such old binaries in stretch? Are such old binaries
still distributed outside Debian? If not, are there any other
objective criteria which is supposed to be met before removing
libstdc++5? Or we are keeping it just for inertia?

Thanks.



Bug#855851: gcc-3.3: still in stretch

2017-02-22 Thread Philipp Kern

severity 855851 wishlist
thanks

On 2017-02-22 14:01, Santiago Vila wrote:

Dear maintainer:

Would be possible to get rid of gcc-3.3 in stretch?

We don't have gcc-5 anymore in stretch, so it would be really strange
that we still need gcc-3.3 (even if it's only the source) which is a
lot older.

If we really need gcc-3.3 in stretch, please downgrade and document
the reason here, so that it serves as documentation.

Thanks.


Why would I need to justify package presence in a serious RC bug? Wat?

It only builds libstdc++5. It's not even a full compiler. That's for 
compatibility with old binaries.


Kind regards
Philipp Kern



Bug#855851: gcc-3.3: still in stretch

2017-02-22 Thread Santiago Vila
Package: src:gcc-3.3
Version: 1:3.3.6ds1-28
Severity: serious

Dear maintainer:

Would be possible to get rid of gcc-3.3 in stretch?

We don't have gcc-5 anymore in stretch, so it would be really strange
that we still need gcc-3.3 (even if it's only the source) which is a
lot older.

If we really need gcc-3.3 in stretch, please downgrade and document
the reason here, so that it serves as documentation.

Thanks.