Discussion:
Bug#799440: myspell-* and hunspell-*: error when trying to install together
Ralf Treinen
2015-09-19 08:45:04 UTC
Permalink
Package: hunspell-af
Version: hunspell-af/1:5.0.1+dfsg-1
Severity: serious
User: ***@debian.org
Usertags: edos-file-overwrite

Date: 2015-09-19
Architecture: amd64
Distribution: sid

Hi,

this concerns a whole list of myspell-X and hunspell-X packages, but I am
filing this bug only against hunspell-af. Here is the complete list:

hunspell-af_myspell-af
hunspell-bg_myspell-bg
hunspell-cs_myspell-cs
hunspell-el_myspell-el-gr
hunspell-en-au_myspell-en-au
hunspell-en-gb_myspell-en-gb
hunspell-en-za_myspell-en-za
hunspell-et_myspell-et
hunspell-gd_myspell-gd
hunspell-he_myspell-he
hunspell-hrr_myspell-hr
hunspell-it_myspell-it
hunspell-lt_myspell-lt
hunspell-nl_myspell-nl
hunspell-no_myspell-nb
hunspell-no_myspell-nn
hunspell-pl_myspell-pl
hunspell-pt_myspell-pt-br
hunspell-pt-pt_myspell-pt-pt
hunspell-sk_myspell-sk
hunspell-sl_myspell-sl
hunspell-sv_hunspell-sv-se
hunspell-sw_myspell-sw
hunspell-th_myspell-th
hunspell-uk_myspell-uk

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:


Preconfiguring packages ...
Selecting previously unselected package emacsen-common.
(Reading database ... 10897 files and directories currently installed.)
Preparing to unpack .../emacsen-common_2.0.8_all.deb ...
Unpacking emacsen-common (2.0.8) ...
Selecting previously unselected package dictionaries-common.
Preparing to unpack .../dictionaries-common_1.26.3_all.deb ...
Adding 'diversion of /usr/share/dict/words to /usr/share/dict/words.pre-dictionaries-common by dictionaries-common'
Unpacking dictionaries-common (1.26.3) ...
Selecting previously unselected package hunspell-af.
Preparing to unpack .../hunspell-af_1%3a5.0.1+dfsg-1_all.deb ...
Unpacking hunspell-af (1:5.0.1+dfsg-1) ...
Selecting previously unselected package myspell-af.
Preparing to unpack .../myspell-af_1%3a3.3.0-4_all.deb ...
Unpacking myspell-af (1:3.3.0-4) ...
dpkg: error processing archive /var/cache/apt/archives/myspell-af_1%3a3.3.0-4_all.deb (--unpack):
trying to overwrite '/usr/share/hunspell/af_ZA.aff', which is also in package hunspell-af 1:5.0.1+dfsg-1
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Processing triggers for man-db (2.7.3-1) ...
Errors were encountered while processing:
/var/cache/apt/archives/myspell-af_1%3a3.3.0-4_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

/usr/share/hunspell/af_ZA.aff
/usr/share/hunspell/af_ZA.dic

This bug has been filed against both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may then
also register in the BTS that the other package is affected by the bug.

-Ralf.

PS: for more information about the detection of file overwrite errors
of this kind see http://qa.debian.org/dose/file-overwrites.html.
Mattia Rizzolo
2015-09-19 13:40:52 UTC
Permalink
Post by Ralf Treinen
this concerns a whole list of myspell-X and hunspell-X packages, but I am
I was kinda looking for this bug, actually. It's somewhat difficult to
find out everything when you have a so large number of packages.
Anyway, I truly expected some less...


[re-sorting the list]
Post by Ralf Treinen
hunspell-af_myspell-af
hunspell-en-gb_myspell-en-gb
hunspell-en-za_myspell-en-za
hunspell-it_myspell-it
hunspell-sw_myspell-sw
hunspell-th_myspell-th
These come from src:openoffice.org-dictionaries, which I want to somehow
remove, so I added transitive packages + breaks/replaces for them.
Post by Ralf Treinen
hunspell-sl_myspell-sl
This one is orphaned, and the source contains only the hunspell
patterns. So, I decided to take it over.
Added a transitional package and breaks/replaces here too.
Post by Ralf Treinen
hunspell-lt_myspell-lt
This one is orphaned too. I looked to take it over too, but there are a
couple of binaries whith stuff that wouldn't fit in lo-dicts. So I'll
stop building this binary altogether.
Post by Ralf Treinen
hunspell-hrr_myspell-hr
Here there is a typo: hrr → hr. I corrected it, but I'll just ignore
the conseguences since this package existed only for one day...
(it fits in the section below)
Post by Ralf Treinen
hunspell-bg_myspell-bg
hunspell-cs_myspell-cs
hunspell-el_myspell-el-gr
hunspell-en-au_myspell-en-au
hunspell-et_myspell-et
hunspell-gd_myspell-gd
hunspell-he_myspell-he
hunspell-nl_myspell-nl
hunspell-no_myspell-nb
hunspell-no_myspell-nn
hunspell-pl_myspell-pl
hunspell-pt_myspell-pt-br
hunspell-pt-pt_myspell-pt-pt
hunspell-sk_myspell-sk
hunspell-sv_hunspell-sv-se
hunspell-uk_myspell-uk
The same with those. Most of them are really old, but none of them
actually orphaned. Two/three of them actually deserves their separated
packages because they are actively maintained, but really most of them
got no uploads in the last 2/3 years...
For now I'll stop building those.
It's sad, I'd have expected really less packages here.
--
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: http://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Agustin Martin
2015-09-21 11:23:39 UTC
Permalink
Post by Mattia Rizzolo
Post by Ralf Treinen
this concerns a whole list of myspell-X and hunspell-X packages, but I am
I was kinda looking for this bug, actually. It's somewhat difficult to
find out everything when you have a so large number of packages.
Anyway, I truly expected some less...
[re-sorting the list]
Post by Ralf Treinen
hunspell-af_myspell-af
hunspell-en-gb_myspell-en-gb
hunspell-en-za_myspell-en-za
hunspell-it_myspell-it
hunspell-sw_myspell-sw
hunspell-th_myspell-th
These come from src:openoffice.org-dictionaries, which I want to somehow
remove, so I added transitive packages + breaks/replaces for them.
Post by Ralf Treinen
hunspell-sl_myspell-sl
This one is orphaned, and the source contains only the hunspell
patterns. So, I decided to take it over.
Added a transitional package and breaks/replaces here too.
Note that both contain the same patterns and words. No upstream watch, so
better tracked from libreoffice.
Post by Mattia Rizzolo
Post by Ralf Treinen
hunspell-hrr_myspell-hr
Here there is a typo: hrr → hr. I corrected it, but I'll just ignore
the conseguences since this package existed only for one day...
(it fits in the section below)
These also contain the same patterns and words. Seems OK to disable it in
lo-dicts.
Post by Mattia Rizzolo
Post by Ralf Treinen
hunspell-el_myspell-el-gr
Same aff file in current versions, so it is indeed a myspell dict. dic
files are different, but I cannot really compare. lo dict seems however,
based in an old 0.7 version, while myspell-el-gr contains 0.8 (and there is
a 0.9 upstream version waiting). Seems OK to disable it in lo-dicts.
Post by Mattia Rizzolo
Post by Ralf Treinen
hunspell-et_myspell-et.
Same contents in both. OK to disable it in lo-dicts.
Post by Mattia Rizzolo
Post by Ralf Treinen
hunspell-pt_myspell-pt-br
BTW, shouldn't hunspell-pt be hunspell-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.
Post by Mattia Rizzolo
Post by Ralf Treinen
hunspell-pt-pt_myspell-pt-pt
hunspell-pt-pt dictionary here is an hunspell-only dictionary, so it
deserves it's own package. I will add a break against hunspell-pt-pt in
myspell-pt-pt 20091013-10, but I think hunspell-pt-pt should stay, but
conflicting with myspell-pt-pt (<=20091013-10) and replacing it. Once it
is minimaly tested in Debian I can make myspell-pt-pt a transitional
package to ensure a smooth transition to hunspell-pt-pt.

Regards,
--
Agustin
Mattia Rizzolo
2015-09-21 15:33:16 UTC
Permalink
On Mon, Sep 21, 2015 at 01:23:39PM +0200, Agustin Martin wrote:

Thanks for your email here!
Given that you are involved with several packages with dicts you find
your input here important and valuable :)
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.
Post by Agustin Martin
Post by Mattia Rizzolo
Post by Ralf Treinen
hunspell-hrr_myspell-hr
Here there is a typo: hrr → hr. I corrected it, but I'll just ignore
the conseguences since this package existed only for one day...
(it fits in the section below)
These also contain the same patterns and words. Seems OK to disable it in
lo-dicts.
I disabled hyphen-hr, but kept hunspell-hr, conflicting with myspell-hr.
The last maintainer upload was in 2009, with 3 (the number 2 seems to
have been lost somewhere...) different, quite large NMUs and a really
simple bug is sitting in the BTS.
I'd rather just take over everything, tbh.
Post by Agustin Martin
Post by Mattia Rizzolo
Post by Ralf Treinen
hunspell-el_myspell-el-gr
Same aff file in current versions, so it is indeed a myspell dict. dic
files are different, but I cannot really compare. lo dict seems however,
based in an old 0.7 version, while myspell-el-gr contains 0.8 (and there is
a 0.9 upstream version waiting). Seems OK to disable it in lo-dicts.
Oh, this one was last uploaded in 2012, the maintainer is not gone at
least (I see an upload from him in 2014-10), the 0.9 seems to be from
2015-03-14. I opened a bug at TDF [0] to update the dictionaries there.
Anyway, there is a Conflicts: in place there too.

[0] https://bugs.documentfoundation.org/show_bug.cgi?id=94415
Post by Agustin Martin
Post by Mattia Rizzolo
Post by Ralf Treinen
hunspell-et_myspell-et.
Same contents in both. OK to disable it in lo-dicts.
This one is really up-to-date and maintained, and actually it Provides:
hunspell-et.
I think it's sane/wise to disable it in our part (done in git)
Post by Agustin Martin
Post by Mattia Rizzolo
Post by Ralf Treinen
hunspell-pt_myspell-pt-br
BTW, shouldn't hunspell-pt be hunspell-pt-br?
Itt should. The very same way pt-pt is named pt-pt (annoying, this
means another NEW trip...)
Post by Agustin Martin
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?
Post by Agustin Martin
Post by Mattia Rizzolo
Post by Ralf Treinen
hunspell-pt-pt_myspell-pt-pt
hunspell-pt-pt dictionary here is an hunspell-only dictionary, so it
deserves it's own package. I will add a break against hunspell-pt-pt in
myspell-pt-pt 20091013-10, but I think hunspell-pt-pt should stay, but
conflicting with myspell-pt-pt (<=20091013-10) and replacing it. Once it
is minimaly tested in Debian I can make myspell-pt-pt a transitional
package to ensure a smooth transition to hunspell-pt-pt.
nice!
Currently there is naked "Conflicts: myspell-pt-pt" (i.e. unversioned).
Though your paragraph here sounds awkward: does myspell-pt-pt deserve or
not its own package? :) (I belive you missed a "don't" in the second
line).
--
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: http://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Agustin Martin
2015-09-21 16:41:16 UTC
Permalink
Post by Mattia Rizzolo
Thanks for your email here!
Given that you are involved with several packages with dicts you find
your input here important and valuable :)
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.
Hi, Mattia

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,

myspell-da: Breaks hunspell-da
myspell-eo: Breaks hunspell-eo
myspell-es: Breaks hunspell-es
myspell-et: Breaks hunspell-et and hyphen-et
myspell-fo: Breaks hunspell-fo
myspell-lv: Breaks hunspell-lv and hyphen-lv
myspell-tl: Breaks hunspell-tl
Post by Mattia Rizzolo
Post by Agustin Martin
Post by Mattia Rizzolo
Post by Ralf Treinen
hunspell-hrr_myspell-hr
Here there is a typo: hrr → hr. I corrected it, but I'll just ignore
the conseguences since this package existed only for one day...
(it fits in the section below)
These also contain the same patterns and words. Seems OK to disable it in
lo-dicts.
I disabled hyphen-hr, but kept hunspell-hr, conflicting with myspell-hr.
The last maintainer upload was in 2009, with 3 (the number 2 seems to
have been lost somewhere...) different, quite large NMUs and a really
simple bug is sitting in the BTS.
I'd rather just take over everything, tbh.
Fine, just do not forget to try contacting maintainer first,
Post by Mattia Rizzolo
Post by Agustin Martin
Post by Mattia Rizzolo
Post by Ralf Treinen
hunspell-el_myspell-el-gr
Same aff file in current versions, so it is indeed a myspell dict. dic
files are different, but I cannot really compare. lo dict seems however,
based in an old 0.7 version, while myspell-el-gr contains 0.8 (and there is
a 0.9 upstream version waiting). Seems OK to disable it in lo-dicts.
Oh, this one was last uploaded in 2012, the maintainer is not gone at
least (I see an upload from him in 2014-10), the 0.9 seems to be from
2015-03-14. I opened a bug at TDF [0] to update the dictionaries there.
Anyway, there is a Conflicts: in place there too.
[0] https://bugs.documentfoundation.org/show_bug.cgi?id=94415
Post by Agustin Martin
Post by Mattia Rizzolo
Post by Ralf Treinen
hunspell-et_myspell-et.
Same contents in both. OK to disable it in lo-dicts.
hunspell-et.
I think it's sane/wise to disable it in our part (done in git)
Thanks, fine. As written above, I also made myspell-et break hunspell-et
and hyphen-et.
Post by Mattia Rizzolo
Post by Agustin Martin
Post by Mattia Rizzolo
Post by Ralf Treinen
hunspell-pt_myspell-pt-br
BTW, shouldn't hunspell-pt be hunspell-pt-br?
Itt should. The very same way pt-pt is named pt-pt (annoying, this
means another NEW trip...)
Post by Agustin Martin
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.

Where those transitional packages appear is a bit chaotic, for aspell there
is an standalone aspell-pt source package that will pull both and for
myspell it ts in myspell.pt sources (European portuguese).
Post by Mattia Rizzolo
Post by Agustin Martin
Post by Mattia Rizzolo
Post by Ralf Treinen
hunspell-pt-pt_myspell-pt-pt
hunspell-pt-pt dictionary here is an hunspell-only dictionary, so it
deserves it's own package. I will add a break against hunspell-pt-pt in
myspell-pt-pt 20091013-10, but I think hunspell-pt-pt should stay, but
conflicting with myspell-pt-pt (<=20091013-10) and replacing it. Once it
is minimaly tested in Debian I can make myspell-pt-pt a transitional
package to ensure a smooth transition to hunspell-pt-pt.
nice!
Currently there is naked "Conflicts: myspell-pt-pt" (i.e. unversioned).
Though your paragraph here sounds awkward: does myspell-pt-pt deserve or
not its own package? :) (I belive you missed a "don't" in the second
line).
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.

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.

Did not check, but you may also need to add some links in migrations,
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.

Regards,
--
Agustin
Mattia Rizzolo
2015-09-21 17:44:36 UTC
Permalink
Post by Agustin Martin
Post by Mattia Rizzolo
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.
Post by Agustin Martin
myspell-da: Breaks hunspell-da
myspell-eo: Breaks hunspell-eo
myspell-es: Breaks hunspell-es
myspell-et: Breaks hunspell-et and hyphen-et
myspell-fo: Breaks hunspell-fo
myspell-lv: Breaks hunspell-lv and hyphen-lv
myspell-tl: Breaks hunspell-tl
Post by Mattia Rizzolo
Post by Agustin Martin
Post by Ralf Treinen
hunspell-el_myspell-el-gr
Same aff file in current versions, so it is indeed a myspell dict. dic
files are different, but I cannot really compare. lo dict seems however,
based in an old 0.7 version, while myspell-el-gr contains 0.8 (and there is
a 0.9 upstream version waiting). Seems OK to disable it in lo-dicts.
Oh, this one was last uploaded in 2012, the maintainer is not gone at
least (I see an upload from him in 2014-10), the 0.9 seems to be from
2015-03-14. I opened a bug at TDF [0] to update the dictionaries there.
Anyway, there is a Conflicts: in place there too.
[0] https://bugs.documentfoundation.org/show_bug.cgi?id=94415
Already got fixed, so the next upstream update will also ship an updated
hunspell dictionary.
I'll keep the conflicts, and ask him if I can take it over too.
I think I need to set up something to check for available updates of the
dictionaries in there, can't be so many updates, that way I can also
help keeping that big container of lo-dicts up-to-date.
Post by Agustin Martin
Post by Mattia Rizzolo
Post by Agustin Martin
Post by Ralf Treinen
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
 ;)
Post by Agustin Martin
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?
Post by Agustin Martin
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?
Post by Agustin Martin
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?
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.

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.
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).
Post by Agustin Martin
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
:)
--
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: http://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Agustin Martin
2015-09-21 18:44:07 UTC
Permalink
Post by Mattia Rizzolo
Post by Agustin Martin
Post by Mattia Rizzolo
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.
Post by Mattia Rizzolo
Post by Agustin Martin
Post by Mattia Rizzolo
Post by Agustin Martin
Post by Ralf Treinen
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.
Post by Mattia Rizzolo
Post by Agustin Martin
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.
Post by Mattia Rizzolo
Post by Agustin Martin
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.
Post by Mattia Rizzolo
Post by Agustin Martin
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.
Post by Mattia Rizzolo
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.
Post by Mattia Rizzolo
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.
Post by Mattia Rizzolo
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.
Post by Mattia Rizzolo
Post by Agustin Martin
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
Rene Engelhard
2015-09-21 19:20:33 UTC
Permalink
Post by Agustin Martin
Post by Mattia Rizzolo
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.
Yes.
Post by Agustin Martin
Post by Mattia Rizzolo
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.
Yes.
Post by Agustin Martin
Post by Mattia Rizzolo
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-*.
The problem is to find out who did what because _of course_ that is rarely
(if never) documented :/

I am so sure that we have myspell-* packages actually using hunspell features
and that they needed a rename.

Regards,

Rene
Andreas Beckmann
2015-09-20 13:29:52 UTC
Permalink
reassign -1 src:libreoffice-dictionaries 1:5.0.1+dfsg-1
Post by Ralf Treinen
this concerns a whole list of myspell-X and hunspell-X packages, but I am
...
to which I'd like to add

hunspell-da=1:5.0.1+dfsg-1 myspell-da=1.6.36-7
hunspell-hu=1:5.0.1+dfsg-1 myspell-hu=1.6.1-2


Andreas
Debian Bug Tracking System
2015-09-22 18:03:12 UTC
Permalink
Your message dated Tue, 22 Sep 2015 18:00:17 +0000
with message-id <E1ZeRrV-0000Jx-***@franck.debian.org>
and subject line Bug#799440: fixed in libreoffice-dictionaries 1:5.0.1+dfsg-2
has caused the Debian Bug report #799440,
regarding myspell-* and hunspell-*: error when trying to install together
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ***@bugs.debian.org
immediately.)
--
799440: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799440
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
Loading...