On Tue, Oct 11, 2011 at 12:26:10PM +0400, Alexander GQ Gerasiov wrote:
> Mon, 10 Oct 2011 12:28:46 +0200
> Agustin Martin <[email protected]> wrote:
>
> > By the way, please consider raising dictionaries-comon-dev
> > build-depend in your hunspell-ru package to at least 1.10.5, where
> > ancient openoffice.org snippets stopped being installed. Your package
> > is OK, and is indeed built matching that condition but if rebuilt by
> > someone else in e.g. squeeze, will re-introduce that snippets, and
> > that will soon trigger an error for sid. Not having them is no
> > problem for squeeze.
Hi, Alexander,
> I disagree.
> Every packet you are uploading should be built in clean actual
> environment. In such case binary packet would be correct.
> Anyone who don't follow this rule should be punished =)
> If you, instead want to build it in squeeze (e.g. to backport) you
> could use dictionaries-common-dev from squeeze without problem. And you
> will get binary package to be correct for squeeze.
>
> So, adding versioned build dependence will only make backporter's life
> harder.
Which backports? There is absolutely no need of backports neither for
rus-ispell->{irussian,aspell-ru,myspell-ru} nor for hunspell-ru, sid
packages for them should install out of the box in squeeze.
dictionaries-common will stop shipping ancient update-openoffice-dicts at
some time before wheezy release. At that time it will break old
myspell/hunspell dictionaries known to still call update-openoffice-dicts
from maintainer scripts and will have a Breaks list for that.
Versioned Build-Dependency makes sure that old snippets are not provided by
mistake by building in squeeze. If someone wants to do something potentially
breaking something else, should do a change and should know what is doing.
Actually, for sid rus-ispell a tighter Build-dependency is needed, since
uses in building a feature that was made available in
dictionaries-common-dev 1.11.2. But the resulting package should work in
squeeze.
Regards,
--
Agustin
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
