Am Freitag, den 21.02.2014, 18:16 +0100 schrieb Agustin Martin: > On Tue, Feb 18, 2014 at 10:17:29PM +0100, Tobias Frost wrote:
> > Just one question: disabling auto-compat does not have any effect > > anymore? (I think thats good, just want to ensure that this was > > intended) > > If it is not in info file it is recreated internally and its data used. If > it is in info file, compat data in info file is used Ok > > When I'm back from my business trip, I will then proceed to start the > > discussion for the overhaul of the simple aspell directoires on > > debian-devel et.al, if that is ok with you. > > What do you exactly plan? The problem with dictionaries in general is the > same as with many other pieces of software in Debian, very different types of > maintainers. As usual when people are involved, this time from all over the world in many different cultures :) > While is OK to let them know about what we are doing, so the most active can > test things, I'd prefer to wait a bit more for something more ambitious, and > if changes are required, let them be for a good reason and do them just once > if possible. See below for more info. > > I wrote > > > Lived this before :-( (http://bugs.debian.org/310590#48), seems this is > > > not > > > possible. I have asked upstream to confirm that to be sure. > > > > > > In the meantime I have been thinking that those symlinks could be created > > > by > > > the $class-autobuildhash scripts and record the target .rws and symlink > > > full > > > paths in a file like $compat.remove. This file could be parsed from postrm > > > to make sure hashes and symlinks are removed. If there is no simple way of > > > adding the paths, this could also be useful if multiarch is ever > > > implemented > > > for aspell. > > This is the main reason I woud prefer to wait a bit more. I am currently > working > on this and preliminary steps are working, including that symlinks are no > longer created by installdeb* scripts, but from autobuildhash scripts. This > needs some care because some systems may have /usr mounted "ro" and only > remounted "rw" during dpkg run, but I think I have already dealt with this, > but have to test more. Newly created dictionaries would need a new > dictionaries-common. > > I have also been doing some reorganization of the devel package to put most > common things in a Devel perl module. I would like to have this put together > with the new changes, so everything is tested. > > My roadmap about this is something like: > > a) On Sunday 1.22.0 reaches testing (#737515). > b) Somewhere next week I plan to upload something to fix [#625278: > dictionaries-common: package contains two dangling symbolic links in > /usr/lib/ispell]. > > While I consider this harmless and something that should be considered a > false positive by any checking tool, I admit it is not nice. This suffers > from the same "ro" problem as creating symlinks from autobuildhash scripts, > and I plan deal with it similarly, here during main dpkg run while in > triggers for the autobuildhash scripts. This has the advantage that will > provide more testing. > c) By that time I plan to prepare an experimental package with all the new > changes, to start further testing. The plan is to ask these people, for their feedback and input and eventually if they're ok to update the (simple) aspell-xx packages, if that leads to improvment for Devian archive. As an example, enabling auto-compat will also eliminate some nasty piuarts errors and debsums false positives. I think, with dh_aspell-simple now in place, many will be happy to make Debian better here, especially when provided with patches. But IMHO that's the second step, the first is to let the people know that there are some changes (planned) and ask for testing, comments, concerns and maybe even ideas. But I think that can also wait a little until you give the "GO" telling that you think everything is now stable enough. Just give me a ping e.g for testing... > Unless important bug reports appear, this should happen in less time than a > bug report needs to be archived, so we could still use this bug report for > coordination or open a new one. > Regards, > > -- > Agustin > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
