On Wed, Aug 18, 2010 at 09:50:21PM +0300, George Danchev wrote: > Yavor Doganov writes: > > ?????? ?????? wrote: > > > Yes, I received that > > > > OK, sorry I got the opposite impression. > > > > > However, it doesn't strike me like extremely elegant design to ship > > > a file with the package (to please certain design decisions taken in > > > another package, dictionaries-common in that case) which will then > > > be regenerated by the maintainer scripts. > > > > AFAICT, you don't have to ship an empty file in the package [1], you > > just have to take care to remove it. It's just that Anton decided to > > do this for bg.rws, so I followed the same approach for the other > > file. > > > > [1] The manpage uses the mild words "You are also suggested to..." > > In opinion, that suggestion is suboptimal, if not entirely wrong. I believe > the man-page should not recommend such approach at all, but let's see what > the > maintainer's comments on that matter.
This has exactly the same security risks that handling everything from maintainer scripts while has the advantage of knowing which package owns the file and being more robust. The only drawback is that during the installation process there is a (normally short) time where hash is not available. This has been discussed some times in debian-devel, with different points of view involved. > > > I really want to get to the bottom of it whether > > > aspell-autobuildhash really needs the approach mentioned in the > > > man-page. > > > > It doesn't need it, I think (a proof is that bg-en.rws was not a file > > in the package before bgoffice/3.0-11, but it was still generated). > > The only discomfort is having unowned files in /var/lib/aspell, and > > taking care to remove them manually on remove/purge. Right, as long as you care about removing relevant files from removal maintainer scripts and create an empty compat file from postinst on configuration (or from preinst on install|upgrade and from postinst on re-configuration if you want hashes for different dictionaries be created together), all before common script is run. No need to create empty hashes this way. > > Probably the process could be triggerized, if it's not too much work. > > Could be., though that would require corresponding tweaking on the > dictionaries-common package too. Things are done just once, so there is no advantage in triggerizing this. That is why I never looked into that (and also because I did not find the time for that). Cheers, -- Agustin -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
