Hello

We, sdl maintainers, made a recent change in our package by removing
unnecessary build depends on -dev packages [1].

Unfortunately, some package did rely on this "extra" dependencies and went
ftbs [2].

Now is the question of possible impact (FTBS) on all packages build-depending
on sdl package (about 400 of them).

Hence the question, how often is a given package rebuilt as part of the FTBS
tests ?

In other words, knowing that new libsdl1.2-dev package was uploaded on April
10, can we be confident that all potential ftbs were detected ?

Given that freeze time in quite close, we are considering to put back the
extra build dependencies if too many packages are impacted. We'd then clean up
after Wheeze release.

All the best

[1]
http://packages.debian.org/changelogs/pool/main/libs/libsdl1.2/libsdl1.2_1.2.15-3/changelog
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669571
For the record, these ftbs are now all fixed
--
https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201205041008.44819.dod@debian.org">http://lists.debian.org/201205041008.44819.dod@debian.org

On Fri, 4 May 2012 10:08:44 +0200
Dominique Dumont <dod@debian.org> wrote:

> We, sdl maintainers, made a recent change in our package by removing
> unnecessary build depends on -dev packages [1].

... at which point you should have looked at the list of reverse
dependencies and done some tests yourselves before uploading ...

i.e. not rebuild all 400 necessarily but to identify those which of
those 400 do not already build-depend on the packages you removed and at
least let the maintainers of the packages know that your change may
reveal an RC bug in their packages.

There are plenty of tools in Debian which can make such a script
possible.

> Unfortunately, some package did rely on this "extra" dependencies and went
> ftbs [2].

... which could, arguably, be jointly your fault as this could have
been handled cleanly if done so in advance. Yes, the maintainer of the
other packages made a mistake by relying on indirect dependencies (it's
usually best to build-depend on everything you check for in your
configure stage) but that bug was revealed by your change, so it would
have been helpful to raise this as a problem in advance.

> Now is the question of possible impact (FTBS) on all packages build-depending
> on sdl package (about 400 of them).
> Hence the question, how often is a given package rebuilt as part of the FTBS
> tests ?

Maintainers should not rely on the periodic but not guaranteed FTBFS
checks run by other maintainers in their free time and out of their own
desire for quality assurance. It isn't a *service* to do your work for
you, it is a valuable contribution which should never be taken for
granted.

> In other words, knowing that new libsdl1.2-dev package was uploaded on April
> 10, can we be confident that all potential ftbs were detected ?

No. You do that yourselves, in combination with the relevant
maintainers.

> Given that freeze time in quite close, we are considering to put back the
> extra build dependencies if too many packages are impacted. We'd then clean up
> after Wheeze release.

How about doing the real work instead and identifying which packages
might be affected, alerting those maintainers and starting a few
rebuild tests of this shortened list? Then you've got some real data
to make the decision about what to do.

Rebuild tests are not restricted only to Lucas, grateful as we all are
for his time in doing them.

Most of us do not routinely rebuild our own packages without some
reason to do so - we may watch on planet.d.o for changes in important
packages, we may read stuff on lists and bug reports but we need to
*know* that there could be a problem and then be given time to make the
necessary upload *before* the breakage is created.

Communication is helpful - causing possibly a few hundred RC bugs is
*not helpful*, whether close to a freeze or not.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Neil Williams <codehelp@debian.org> writes:
> Dominique Dumont <dod@debian.org> wrote:

>> We, sdl maintainers, made a recent change in our package by removing
>> unnecessary build depends on -dev packages [1].

> ... at which point you should have looked at the list of reverse
> dependencies and done some tests yourselves before uploading ...

While this would be nice if Dominique had the time, I disagree with the
"should" part of this sentence. Working around bugs in other people's
packages shouldn't be a requirement. It's certainly *appreciated* if one
wants to go to the work of finding and reporting those bugs, but to me
that's a general Debian bug fixing task, not something for which the -dev
package maintainer has any special responsibility.

> ... which could, arguably, be jointly your fault as this could have been
> handled cleanly if done so in advance. Yes, the maintainer of the other
> packages made a mistake by relying on indirect dependencies (it's
> usually best to build-depend on everything you check for in your
> configure stage) but that bug was revealed by your change, so it would
> have been helpful to raise this as a problem in advance.

For "usually best" please replace "mandatory and required by Policy"
except for some cases where packages are *defined* as providing the
necessary interfaces as part of their purpose. (dh-autoreconf, for
example.) The packages that don't have accurate build dependencies are
the ones at "fault" here.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87mx5one87.fsf@windlord.stanford.edu">http://lists.debian.org/87mx5one87.fsf@windlord.stanford.edu

Le Friday 4 May 2012 11:09:52, Neil Williams a écrit :
> Dominique Dumont <dod@debian.org> wrote:
> > We, sdl maintainers, made a recent change in our package by removing
> > unnecessary build depends on -dev packages [1].
>
> ... at which point you should have looked at the list of reverse
> dependencies and done some tests yourselves before uploading ...
>
> i.e. not rebuild all 400 necessarily but to identify those which of
> those 400 do not already build-depend on the packages you removed and at
> least let the maintainers of the packages know that your change may
> reveal an RC bug in their packages.

Sorry, no. SDL team was recenty reconstructed from scratch [1] and we have
only 2 active people. I don't count myself as active in sdl team as I mostly
do package reviews and upload. We just don't have the time to perform what you
suggest just to compensate for easy-to-fix packaging mistakes.

> > Unfortunately, some package did rely on this "extra" dependencies and
> > went ftbs [2].
>
> ... which could, arguably, be jointly your fault as this could have
> been handled cleanly if done so in advance.

Not my fault, nor current team's fault: this mistake was done years ago. We
are still cleaning up what we found.

> Yes, the maintainer of the
> other packages made a mistake by relying on indirect dependencies (it's
> usually best to build-depend on everything you check for in your
> configure stage) but that bug was revealed by your change, so it would
> have been helpful to raise this as a problem in advance.

Agreed. I admit I did not foresee the potential problem.

> How about doing the real work instead and identifying which packages
> might be affected, alerting those maintainers and starting a few
> rebuild tests of this shortened list? Then you've got some real data
> to make the decision about what to do.

Actually, the whole point of my mail was to gather real data from work already
done. Thanks to Lucas, we know about failing packages. Too bad we don't know
about succeeding packages.


All the best

[1] http://ddumont.wordpress.com/2011/11/19/sdl-team-revival/

Dominique

On Sat, 5 May 2012 11:34:45 +0200
Dominique Dumont <dod@debian.org> wrote:

> > i.e. not rebuild all 400 necessarily but to identify those which of
> > those 400 do not already build-depend on the packages you removed and at
> > least let the maintainers of the packages know that your change may
> > reveal an RC bug in their packages.
>
> Sorry, no. SDL team was recenty reconstructed from scratch [1] and we have
> only 2 active people. I don't count myself as active in sdl team as I mostly
> do package reviews and upload. We just don't have the time to perform what you
> suggest just to compensate for easy-to-fix packaging mistakes.

It really isn't that much work to scan through apt-cache rdepends and
then check that against Sources.gz to get a list of collated
Build-Depends.

If the new team don't have time to write and run a short script then
maybe the package would have been better off without the upload.
Maintenance is not about being an automaton with a GPG key and a
package review should include the implications of the changes on
other packages which use the package being reviewed.

> > > Unfortunately, some package did rely on this "extra" dependencies and
> > > went ftbs [2].
> >
> > ... which could, arguably, be jointly your fault as this could have
> > been handled cleanly if done so in advance.
>
> Not my fault, nor current team's fault: this mistake was done years ago. We
> are still cleaning up what we found.

The original mistake, yes, but then the package didn't FTBFS. Those
failures arise from the change you made. Albeit for sensible reasons but
not *compulsory* reasons - there is no requirement to drop unnecessary
build-dependencies, the requirement is not be lacking build
dependencies. IMHO it's perfectly acceptable to have redundant
build-dependencies *where removing them would cause breakage elsewhere*
as this gives an opportunity to get those issues fixed smoothly.

What has been achieved by removing those build-dependencies? Your
package is a bit cleaner and Debian is a bit more broken. Gee, thanks.
Less work for you, more work for the rest of us and without even a
heads-up or thought of the consequences. Sounds like you're taking more
than just Lucas for granted.

I don't seek to diminish the problems in the other packages - as Russ
points out, those packages are already ignoring Policy - but solving
those Policy issues without generating RC bugs en masse would have been
so much better.

In effect, the package upload has induced a mass bug filing without any
checks or attempts at detection let alone prevention, in the expectation
that someone else will not only pick up the pieces but identify where
things have been broken by *your* change.

To not even bother checking what might break until *AFTER* the upload
is beyond careless, it is presumptive. Maintainers of libraries have
responsibilities to the maintainers of packages which are reverse
dependencies - those include handling things like SONAME changes API
breakage cleanly and alerting them to upcoming changes with sufficient
time that packages can be adapted without breakage. If time is allowed
and nothing happens, so be it, but to upload and then confess to the
breakage only after packages have failed to build is poor.

> Actually, the whole point of my mail was to gather real data from work already
> done. Thanks to Lucas, we know about failing packages. Too bad we don't know
> about succeeding packages.

That would have been fine but the upload had been made without this
check being done. This could have been so much better if the discussion
had preceded the upload.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Le Saturday 5 May 2012 12:29:03, Neil Williams a écrit :
> That would have been fine but the upload had been made without this
> check being done. This could have been so much better if the discussion
> had preceded the upload.

ok. there's a misunderstanding. I do not want to justify the upload that was
done without prior communication: This was a mistake. Mistakes happens. If a
similar situation occurs, proper communication will be done before upload.


All the best

Dominique