On Fri, Aug 20, 2010 at 08:08:10AM +0300, George Danchev wrote: > Agustin Martin writes: > > 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. > > On the contrary, having knowing which package owns that file name, where > hashsum mismatches or is not present at all, does not add any trust or > robustness, but weirdness leading to suspicion, and a willingness to > investigate what exactly is going on.
Sorry for the delay, I have limited time these days. As long as that is what is shipped by the package that should trigger no more than curiosity. Note that policy does not require all shipped files to have an associated shipped checksum (that is also why dh_md5sums has an -X option). Also note that we are speaking about things under the /var/lib hierarchy, where things are expected to change. The curious thing there would be the presence of an inmutable file that is not a text file explaining what some things there mean, or something like that. Last time this was discussed in debian-devel, see thread started by http://lists.debian.org/debian-devel/2010/03/msg00038.html there were different points of view involved, * People (other than me) that did not seem worried about this, * People that pointed out that this makes the hash unavailable during an usually short time, but for no good reason. This is indeed an interesting point. I am in some semi-VAC and replied to your earlier mail before reading that squeeze is frozen. In the lenny->squeeze transition there is no binary incompatibility between old and new ispell and aspell hashes, so having used a different approach (closer to yours) would have the hash unavailable only for the fraction of second needed for its rebuild instead of having it unavailable for the time elapsed between unpack and configuration during a large upgrade. I am considering changes, but because of this reason. * People that considered that all shipped files must have an accompanying checksum. Even with this, I think that files under the /var/lib hierarchy whose original md5sum is 'd41d8cd98f00b204e9800998ecf8427e' (as those created by touch or >test-file) should be taken with a grain of salt (warned about differently) regarding changes, because they have a high chance of being placeholders. IIRC other people proposed, in addition to this, to have some way of letting dpkg know about files created from maintainer scripts, so is easier to know where they come from. > Sure, we can abuse the system in various weird ways, but should we. This is a currently legitimate use (that of course can be improved). -- Agustin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
