Re: osmgpsmap not migrating to testing

[Niels Thykier <niels@thykier.net>]

On 2014-08-10 20:38, Ross Gammon wrote:
> Hi,
> 

Hi Ross,

Thanks for taking your time reviewing and following up on a stuck
testing migration. In particular, thanks for also looking at the reverse
dependencies of your package.

> [...]
> 
> Would it be possible to unblock osmgpsmap?
> 
> As I am a fairly new maintainer, any other advice would be appreciated.
> 
> Regards,
> 
> Ross Gammon
> 


It is possible to make osm-gps-map a valid candidate, which would make
it possible for it to migrate.  But what is needed is not an "unblock",
instead you need "decruft".

Your package is basically in middle of a transition; but since it is not
in testing, it is not on caught by our auto-transition detection tool.

The process from here
=====================

*In the particular case*, here is how I suggest we handle this:

 * You bump #748386 to serious (or have it fixed).
 * Once that is done, I will ask the FTP master to carry out the
   "decruft" *breaking unfixed reverse dependencies* of the binaries
   being removed (see below).


Be advised that this strategy is not always applicable.  But since
none of the affected packages are in testing, there is nothing to
lose from our (the RT's) perspective.



Longer story / more info for next time
======================================

The osm-gps-map package is currently only blocked by "out-of-date"
binaries.  While it can occur for several reasons, your particular case
appears to be a "transition".  Basically, osm-gps-map used to build

 * libosmgpsmap-dev
 * libosmgpsmap2
 * libosmgpsmap2-dbg
 * python-osmgpsmap
 * libosmgpsmap-1.0-dev

While it no longer does, (some of) these still have reverse
dependencies.  To avoid breakage, dak keeps these packages around *in
unstable* until they have no more reverse dependencies[1].

A "decruft" means that these binaries will be removed from unstable
causing all reverse dependencies to be uninstallable (having lost one of
their dependencies).

Note that unless your package is listed in [daily-cruft], you will have
to file a bug against ftp.debian.org to have your package "decrufted".
In all cases, you want the old binaries removed from *unstable*.  Once
that is done, the particular case of "out of date binary" will go away
on its own.



~Niels

[1] Actually, I believe an FTP master have to manually approve it as
well after that, but they tend to do that regularly - but only for
things that do not cause breakage.

[daily-cruft]: https://ftp-master.debian.org/cruft-report-daily.txt