[Debian-hebrew-common] user-he summary

[Baruch Even]

* Shachar Shemesh <shachar at debian.org> [061103 09:37]:
> Lior Kaplan wrote:
> > Shachar Shemesh wrote:
> >   
> >> Hi all,
> >>
> >> Trying to get to actual action items, the consensus I'm getting is this:
> >>
> >>     * Leave only locales and culmus as depends
> >>     * Demote almost everything else to recommends
> >>     * Don't touch things currently in recommends or suggests
> >>     * Further developments (GUI, special installation program, voice
> >>       recognition etc.) - no consensus yet.
> >>
> >> Is that correct?
> >>     
> >
> > If this the the current depends:
> > aspell-he, bidiv, culmus, firefox-locale-he, hdate-applet, hspell,
> > hspell-gui, kde-i18n-he, kkbswitch, koffice-i18n-he, mlterm, myspell-he,
> > openoffice.org-l10n-he, ttf-freefont
> >
> > I think aspell-he, bidiv, culmus, hspell, myspell-he and ttf-freefont
> > should stay in dpends.
> >   
> I agree to aspell-he, bidiv, culmus and hspell.
> ttf-freefont is, I think, a marginal, as it is not Hebrew specific. I
> think it's good enough in "Recommends", but I'll hold on to what Baruch
> says.

I don't think ttf-freefont is so important, culmus seems to cover all
the needed fonts by itself.

> 
> myspell-he cannot be in recommends so long as it is "extra". It is not
> in the SVN, though we are listed as the maintainers.

If you apt-cache show myspell-he | grep Source you'll see where it comes
from. The hspell package. hspell source creates two binary packages,
hspell and myspell-he, we could also create aspell-he from it but the
aspell maintainer prefers to be able to mungle the aspell dictionaries
and wasn't very helpful in trying to get everything done in the hspell
source package so I left it as it is.

> > No problem with demoting everything else to recommends.
> >
> > ---------------------------------------------------------------------------
> >
> > Please notice that we have a koffice-i18n-he is not available in sid
> > anymore (see #396229). So the packages we upload with a dependency for
> > that package, so when/if user-he will enter testing it won't mention it.
> >   
> Was the package permanently removed? If so, we should remove it from the
> user-he dependencies altogether.

This is strange, the koffice-l10n source package removed the Hebrew
package but there is no mention of it in the changelog.

> > I think we should delay the changes above to after Etch, as I don't want
> > to play too much with the package before the release (and its freeze
> > which should be soon).
> >   
> I don't understand this last statement. We want this package in so that
> users can use it. Nothing depends on it, so it's not like we are likely
> to break anything. There is no freeze yet (in fact, the package is
> already in Etch, only broken due to the myspell-he dependency). I really
> think this is not the right consideration.

> > I just don't want to catch too much for Etch, as it contains a major
> > improvement for Hebrew with 9 new packages for Hebrew support (use
> > http://qa.debian.org/developer.php?login=Debian+Hebrew to compare stable
> >  and testing packages).
> >   
> It's a cost effectiveness question. Since nothing depends on user-he, I
> don't see what the risk is. Since user-he is already in Etch, I can see
> plenty where the damage is.
> 
> In any case, it's not like we are doing any major changes here. We are
> just improving the dependencies. We have not introduces the GUI tool
> (yet?). That, I agree, should not go into Etch.

The point is that we had the package in this form for a while now and
besides the koffice issue there were no bugs or complaints. Changing it
now means that we commit to a different way that will not be tested
sufficiently by users.

I don't think the changes you propose are a big issue, but I'd also
rather do them after etch is released.

Cheers,
Baruch