Bug#799440: myspell-* and hunspell-*: error when trying to install together
On Mon, Sep 21, 2015 at 05:44:36PM +0000, Mattia Rizzolo wrote:
> On Mon, Sep 21, 2015 at 06:41:16PM +0200, Agustin Martin wrote:
> > On Mon, Sep 21, 2015 at 03:33:16PM +0000, Mattia Rizzolo wrote:
> > > On Mon, Sep 21, 2015 at 01:23:39PM +0200, Agustin Martin wrote:
> > > > On Sat, Sep 19, 2015 at 01:40:52PM +0000, Mattia Rizzolo wrote:
> > > After my email Rene suggested me to add Conflicts in most of the cases,
> > > instead of dropping every problematic binary, and a package with them
> > > has already been uploaded, currently in NEW.
> >
> > I also think that is a better approach.
> >
> > In the meantime I have also uploaded some of the dicts I'm involved with,
> > including additional Breaks even if hunspell package is not yet available,
>
> umh, isn't Conflicts needed in this case. They are just plain
> incompatible in the current state of affairs.
Err, yes, thanks for pointing this out.
Although at least with dpkg no unexpected error seems to happen,
dpkg -i myspell-et_20030606-26_all.deb
dpkg: regarding myspell-et_20030606-26_all.deb containing myspell-et:
myspell-et breaks hunspell-et
hunspell-et (version 1:5.0.1+dfsg-1) is present and installed.
dpkg: error processing archive myspell-et_20030606-26_all.deb (--install):
installing myspell-et would break hunspell-et, and
deconfiguration is not permitted (--auto-deconfigure might help)
Errors were encountered while processing:
myspell-et_20030606-26_all.deb
Will try tomorrow with apt to check a bit more in real situation. I am
afraid I'll need yet another bunch of uploads to change it back to conflicts.
> > > > > > hunspell-pt_myspell-pt-br
> > > >
> > > > Both hunspell-pt and myspell-pt-br contain exactly the same dictionary (just
> > > > version string in aff file is changed). I am adding a break in myspell-pt-br
> > > > against any hunspell-pt-br (not yet hunspell-pt), but I think it is OK to
> > > > disable hunspell-pt for now.
> > >
> > > would you add a Provides: hunspell-pt at least?
> >
> > In the meantime, I am adding that dependency. However, note that this is
> > handled differently for aspell and old myspell.
> >
> > For myspell, myspell-pt is a dependency package that will pull both
> > myspell-pt-br and myspell-pt-pt. Similar thing for aspell. I wonder if
> > something like this may be useful for hunspell-pt.
>
> wooops, I meant a Provides: hunspell-pt-br ...
> I do think a hunspell-pt package pulling hunspell-pt-pt and
> hunspell-pt-br makes sense.
> If you think the best place to hold such a metapackage is lo-dicts just
> shut (=open a new bug) and I'd be happy to add it; it's cheap when you
> have ~100 binaries anyway… ;)
Up to you. just let me know, I already added hunspell-pt to provides. Other
thing I considered at some time is a spellcheck-dependencies-pt source
package containing just dependency packages. But I never did it, so is now
your choice for hunspell-pt.
> > It is OK, is hunspell-pt-pt the one that deserves its own package. In this
> > case, upstream is the same for both myspell-pt-pt and hunspell-pt-pt, so
> > I'd expect the change to be smooth and something we can do soon. Just allow
> > a minimal testing of hunspell-pt-pt in real life.
>
> umh, do you mean it's own *source* package here?
> so, what do you suggest now that there is a hunspell-pt-pt in lo-dicts?
No, I meant binary package under lo-dicts umbrella.
> > In other cases like myspell-es vs hunspell-es, upstreams are different and
> > in the meantime, I'd prefer to wait a bit more having two conflicting
> > alternatives available.
>
> wait wat?
Wait to know what people think about both in real usage, that is, have them
both simultaneously in the archive, until one clearly wins. This way we do
not opt by one upstream or another, but users do.
> > Did not check, but you may also need to add some links in migrations,
>
> ok, but to me it seems nothing in debian currently requires myspell, and
> everything (within our archive) migrated to hunspell. What more is
> holding us on just blinding stop providing myspell dictionaries (read it
> as: dictionaries in the myspell directory?
There should be no dictionaries in the myspell directory, using or not
advanced hunspell-only features, all should go in the hunspell directory.
> Also, most of the myspell-* packages I saw where shipping files in the
> hunspell directory, and the others were just symlink them to the myspell
> dir.
Those are buggy, using /usr/share/myspell is deprecated since years ago.
hunspell still looks there also, but that location is more than obsolete.
> What I'm silently trying to do this release cicle is to smooth the way
> to remove all myspell-* packages duing buster, at least for those that
> are de-facto unmaintained, aka the most of them.
We are mixing two things, dictionaries that come from old myspell or early
hunspell (which are also fine to be used for aspell), using a subset of
hunspell features and dictionaries using advanced hunspell-only features.
Both can be used by hunspell, just that first ones were named myspell-*
(or hunspell-* if packaged recently) and the second ones must be named
hunspell-*.
Unless for a given language hunspell-xx contains a different dict than
myspell-xx, myspell-xx->hunspell-xx change would just be a renaming.
> I'm all for singular source packages for dicts, but they need to be
> maintained (this is something valid for everything, but happens that
> most of language stuff here partly abandoned. In fact except for the
> dicts you maintain (!), most of the rest is de-facto orphaned; when I
> looked at this situation I figured out the best way to improve it was to
> get lo-dicts running well again).
I think you are doing the right thing, thanks a lot for caring about this.
Although some of the dicts are properly maintained, in other cases dicts
are typical pet packages. Someome not very involved with Debian gets
it sponsored into the archive and then forgets about it.
> > hunspell fallback dictionary selection still needs implementation (Rene,
> > at some time I will open a wishlist bug against hunspell so the info I
> > have can be found in a common location). Fortunately, libreoffice seems
> > to handle that internally.
>
> Indeed.
> It's just that I won't write them manually for every single language
> there is in lo-dicts, otherwise I can just go run crazy around my home
I strongly think this is something that should be addresed in hunspell
upstream. Otherwise, everybody will go crazy. But bugs may come, that is why
I mentioned it. Cross fingers and hope this do not happen ;-)
Regards,
--
Agustin
Reply to: