2014-02-08 11:19 GMT+01:00 Tobias Frost <t...@frost.de>: > Hallo Augustin, > > thanks for the patch, look and feel of it is very good. > I also tried it on the modified aspell-it (just randomly picked pet > package to test piuparts-happy-dictionaries packaging) and the result > was as expected. > > However, when I disabled "auto-compat" by removing the line in > *.info-aspell something seems goes wrong: > The package then some creates a bogus hashfile name like > HASH(0x6e9848).rws and the installed autoscripts looks like it would > ignore the disabled auto-compat.
Hi, Thanks a lot for the testing, this was a bug at my side. I prepared a preliminary version for simple packages like aspell-it. Then improved it and extended to more complex dicts like aspell-en, and in this step I broke the aspell-it like case :-(. > Talking about auto-compat, I think it would be anyway a good idea to > depreciate NOT using auto-compat or maybe even making it the default > behaviour: Installing the compiled *.rws and then rehashing it on e.g > aspell-updates will make debsums produce wrong warnings. That is what auto-compat and friends are about, provide info to maintainer scripts about which variable files create/remove from them regarding aspell-autobuildhash, so they are not shipped with the package and there are no problems with debsums. In my intended --aspell-simple implementation, if auto-compat data is provided at aspell-info file, it is used, otherwise, if data can be extracted from Makefile.pre and installed .rws, they are used to re-create expected info to be passed to maintainer scripts to properly handle aspell-autobuildhash. > I just have an additional suggestion, however this is just something > something "pedantic". > Currently installdeb-aspell also installs a (dangling) symlink when > auto-compat is turned on. Lintian does emit a experimental warning on > that. (e.g X: aspell-it: package-contains-broken-symlink) > My proposal would be to add a snippet to the preinst-compat and > postrm-compat scripts to create and delete the symlinks. > Please see the attached patch, but please be warned: Perl's not a > language I'm fluent in. Thanks, I will look at it. But I am beginning to think that this is something that should have been dealt with from the very beginning by aspell itself, without the need of any symlink, that is making aspell look for hashes with this precedence /var/lib/aspell /usr/lib/aspell This would make symlinks unneeded and be a cleaner implementation. Not sure if aspell can have more than one search path, but if possible may be the best choice. While we are at this, I would prefer to not add extra complexity to maintainer scripts by now, since further changes may be needed in the future. Current aspell-autobuildhash implementation has a really weak point for the future, multiarch (at the time the system was written we could not even imagine it). On the one hand this would benefit from multi search path, looking at /var/lib/aspell/$arch /var/lib/aspell /usr/lib/aspell but this would also need some extra black magic from maintainer scripts to make sure things are re-created/removed as needed for the different architectures, and this means changes. By the way, I saw no replies from aspell maintainer to [#667592: libaspell15: please add multiarch support] > To start the discussion e.g on debian-devel, dict-common-dev and with > the individual maintainers, can you maybe upload already the current > state to experimental, even if the docs are still incomplete? Let me do some changes to fix the bug you mentioned and do some extra checks myself before that. If I trust enough the result I will upload something. I do not expect to do much work during the weekend and at least on Monday I will be very busy, hope to go back to this after Tuesday or Wednesday. Will let you know. Thanks a lot for the debugging, Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
