[Pkg-kde-extras] Bug#877295: Bug#877295: amarok build-depends on removed package libgpod-nogtk-dev

[Pino Toscano]

In data sabato 30 settembre 2017 16:12:19 CEST, Adrian Bunk ha scritto:
> On Sat, Sep 30, 2017 at 02:04:58PM +0200, Pino Toscano wrote:
> > In data sabato 30 settembre 2017 14:55:34 CEST, Adrian Bunk ha scritto:
> >...
> > > Current status quo in Debian is that it is completely normal that
> > > a new upload of some package is followed by me filing 10-50 RC bugs
> > > against packages that FTBFS due to that change.
> > 
> > No, it is not.  You are mixing two things in the same pot:
> > a) breakages due to side-effect (possibly not known in advance) of new
> >    versions of packages
> > b) well-known breakages that some change is going to cause
> >...
> 
> In the vast majority of the RC bugs I report, the sole difference
> between a) and b) is whether the uploader bothered to check whether
> the new package might break rdeps.

Which you knew, yet ignored.

> gtk-doc-tools 1.26 or Qt 5.9 likely breaking some rdeps is something 
> that is known in advance.

Usually the breakages due to a new version of Qt tend to be very low.

> > My note was a general remark that for things in the (b) category above
> > a pre-emptive email/bug/etc to the interested rdeps *is* the optimal
> > way to interface with other people.  I do not care if other people just
> > dump stuff in unstable and expect other to clean up after the mess they
> > created -- it is simply *not* correct, not even fair.
> 
> #872796 #873023 #873444 #872742 #873020 #874187
> 
> Do you consider it fair that I had to submit bugs to help clean up the 
> mess created by the Qt maintainers dumping 5.9 into unstable without 
> first checking that all their rdeps still build?

a) #872742 was detected during the transition, and was correctly fixed
as part of it (thanks for reporting it)

b) #874187 has nothing to do with Qt, but with the switch to GCC 7

c) Qt 5.9 was not "dumped" into unstable: it was tested with a large DE
(Plasma), and a number of other packages; sure, there were 5 FTBFSes,
and this is what I said earlier with "possibly not known in advance
[side effects]"

d) I don't see anybody forcing you to file bugs to "clean up a mess"
(that did not actually exist); if you didn't have the time/will/etc,
you could have *contacted* the team (see what I already said about
cooperation); using these bugs as excuse like "I break things, since
you broke them" is not exactly a constructive modus operandi, and just
lead to a downhill path in lack of cooperation

e) even said all the above: I don't see how this is relevant to the
note I sent to you over what I saw regarding your libgpod upload;
please do not change the topic like "... so what about the others?"

> > > So when the only rdep is one package that is not in testing and anyways 
> > > requires a (non-trivial) sourceful upload for re-entering testing,
> > > I fail to see any reasonable justification for me to spend additional
> > > time on going through any process longer than just filing an RC bug.
> > 
> > And this is again this very specific case.
> 
> I did this change as part of a QA upload also fixing one of these
> FTBFS I reported but didn't cause (#876583).

Sure, and I don't see how fixing that bug required dropping used (even
if only in unstable) packages.  Again, my note was only regarding the
way a breakage was introduced in Debian, not on the upload as a whole.

-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-extras/attachments/20170930/91420ce3/attachment.sig>