Bug#601959: Bug#577062: junior-toys: missing /etc/blends/blends.conf breaks dist-upgrade

[Andreas Tille]

Hi Steve,

On Mon, Nov 08, 2010 at 12:30:01PM -0800, Steve Langasek wrote:
> severity 577062 serious
> thanks

Thanks for the tagging I was about to do so (should have done earlier)
and to merge it with #601959 (which is actually the very same problem
just filed against science-* but junior packages are mentioned as well.
I was hesitating a bit whether a merge would be apropriate or whether I
should rather open a third bug against debian-med packages as well in
separate.  Finally the problem has to be fixed in blends-dev if not
solved by pre-depends (see below).
 
> As for the proposed change, I disagree that this is the right way to fix it.
> This is not a correct use of pre-depends; nothing in this sequence has a
> logical pre-depends relationship, the problem is entirely due to a buggy
> postrm script in the old version of the package.  The correct way to fix
> this is by adding a postrm script to the *new* version of the individual
> packages, that handles the cleanup on upgrade.  This postrm script should
> check for $1 = failed-upgrade and include an appropriate version check on
> $2, and be a no-op otherwise.

OK.  This needs to be done in blends-dev which was used to build the source
package.
 
> (The proposed patch also includes a change to debian-junior-tasks.desc which
> is not documented in the changelog; please don't include undocumented
> changes in packages that you're requesting a freeze exception for.)

The debian-junior source package is auto-generated by blends-dev which
does a check in the target distribution whether a package is available
or not.  The files which are affected are on one hand debian/control
which puts not available packages to Suggests instead of Recommends on
the other hand it creates a tasksel conftol file
(debian-junior-tasks.desc) which mentions all packages available in the
target distribution.  Thus these changes are automatically generated and
the only reasonable way to mention this in the changelog would be to
create an automated changelog entry.  I do not think that following this
strategy for Squeeze is a good thing to do because I'm afraid the "new
feature" might have unwanted side effects but I'd definitely put it on
my todo list for Squeeze+1.

Kind regards

      Andreas. 

-- 
http://fam-tille.de