Agustin Martin writes: > On Fri, Aug 20, 2010 at 08:08:10AM +0300, George Danchev wrote: --cut-- > > 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.
No worries, this is a priority wishlist, as set with the initial bug submission. Also, it is softa VACish almost anywhere, but I didn't mean to disrupt yours, of course ;-) > 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). Well, this is a good argument, indeed. However debhelper is way too flexible, and during the years took measures to provide maximum options possible to respond to almost any usual and a fair bit of unusual situations. So, I wouldn't quite judge it like that based on its options, but let's count that explanation as acceptable. > 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. I haven't thought of package processing time spans (period off for the file in question to be regenerated), to be honest, but this sounds quite a reasonable reason too. > * 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. Maybe there are ways, I can't think of right now, to expose such 'placeholders' more visibly to the general public, so we won't get surprises. README.Debian might not look quite appropriate in that case, but might eventually suffice. > 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. Interesting idea, which eventually belongs to a dpkg mailing or bugs list. > > 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). Okay. As I see it, it would merely be a documentation fix (the man-page), and identifying the packages which build-depends on that one, to check the road they followed. Anyway, I'd suggest this to be dealt with post squeeze, to eventually allow some more people to comment on that if they wish, and you complete your VAC. -- pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
