patches to wesnoth, or rather general issue with substvar handling

[Gerfried Fuchs]

        Hi!

 First of all, thanks for the fast response, clearly appreciated.
Sometimes I wish some of my upstreams would be as responsive as this
"downstream". ;)

* Emilio Pozuelo Monfort <pochu at ubuntu.com> [2007-10-23 19:12:49 CEST]:
> At one point in the past, libsdl-*1.2-dev packages didn't depend on the
> libsdl1.2-dev package, causing a FTBFS. If you look at the changelog,
> you will see:
> 
>     - Added libsdl1.2-dev to Build-deps (fix FTBFS)
> 
>  -- Emilio Pozuelo Monfort <pochu at ubuntu.com>  Wed, 14 Mar 2007 23:10:08 +0100
> 
> That was in Feisty, and it's fixed now, so we can remove it.

 Though, hmm, such a FTBFS never happend in Debian, was that a libsdl
problem in ubuntu only? This is just a curious question, not meant as a
finger pointing or anything else.

> But why would you remove it? You shouldn't rely on dependencies of
> your build-dependencies, since in the future they can change, causing
> a FTBFS.

 In general you are right. In this case it in fact clearly is a bug that
happened in the libsdl packaging at some point, so adding it explicitly
is a workaround for that breakage. It still makes me wonder a bit... but
given that it doesn't really hurt appart from some few bytes in the
source package I guess I could live with having it explicitly there
instead of implicitly.

> If you have a dependency on a package, shouldn't you put it,
> regardless of the other build-dependencies?

 You are right, just checked, src/video.hpp does #include "SDL.h"
directly. I always thought it's just used indirectly, that's what I
originally thought.

> >  The other thing which is pretty nasty and can give you headaches in
> > cases you would need to do binary-only rebuilds without source
> > changes is a false usage of substvars: Any package, especially Arch:
> > all packages ... that has a versioned dependency on an Arch: any
> > package ... will have to use the ${binary:Version} instead of the
> > ${source:Version} to not create troubles for such uploads.
> 
> We don't do binary-only rebuilds AFAIK, but that isn't a excuse not to fix it ;)

 Thanks. ;)

> I mailed (more than once) to Isaac Clerencia, who is the Debian Maintainer, and
> he told me he was going to add it. Maybe he forgot about it...

 Ah. For such cases, and given that more and more packages are team
maintained these days, or even just in the case of a handover of
packages, I would encourage to use the Debian BTS to send patches along.
That way it is visible for everyone interested in the package, even if
they are not listed in the package responsible section (like,
Uploaders), and not get stuck and hidden in someone's private mailbox.  :)

> Isaac Clerencia wrote:
> > On Saturday, 5 May 2007, Emilio Pozuelo Monfort wrote:

 Ah, may - that was a bit before the time I sort-of "hijacked" the
package from Isaac noticing he was more than busy with other stuff and
helped out bringing the 1.2.5 into the pool finally. Especially the kind
of situation that could had been avoided with sending the patches with
explenations to the Debian BTS.  ;)

> http://launchpadlibrarian.net/9284696/wesnoth_1.2.6-1ubuntu%5B1%2C2%5D.debdiff
> https://launchpad.net/bugs/113361

 This exact patch is one that is a broken approach to a not generated
locale on the user's system. It enables that locale for wesnoth only,
but if the user really wants to use that language they definitely should
be guided to generate the system's locale for that language and not been
worked around that by the --enable-dummy-locale switch. If that is used
they most propably will file the exactly same bugreports against every
other application that offers localization too.

 Another clean approach might be wesnoth check what system locales are
available and just display those languages in the chooser that can be
properly supported. I think I'll try to ask upstream about what they
think about this approach.

> I'll remember to CC you next time I change wesnoth in Ubuntu!

 Please just send it to the BTS and not let it pile up in another's
person personal mailbox. ;)

 So long,
Rhonda