On Wed, Aug 03, 2011 at 12:34:21PM +0100, Ciaran McCreesh wrote: > On Tue, 2 Aug 2011 17:29:29 -0700 > Brian Harring <ferri...@gmail.com> wrote: > > That's not a "massive change" to vdb behaviour either; file > > collisions aren't supposed to occur, as such ownership of the file is > > basically guranteed back to a single package. Throw in > > CONFIG_PROTECT for adjusting the behaviour, and you have a far more > > preferable norm than "lets just leave a shit ton of .pyc/.pyo on the > > fs". > > It is a massive change, since if the feature is there then people don't > feel bad about writing lousy pkg_ functions that leave a load > of .pyc / .pyo files all over the place.
Quoting the good spec: "The unmerge process removes an installed package's files. It is not covered in detail in this specification." Aka, ebuild's should be written to assume the files they install get wiped; there is *zero* mention of mtime, nor could any ebuild rely on it and be compliant. Background as to why we ever relied on mtime- it was a hack to work around a bad implementation in portage (treewalk function); it didn't actually know if it was replacing or what not, so mtime was what was relied on- afaik, that being the sole reason we shoved mtime into the vdb also. At least from the portage standpoint, shifting away from mtime reliance was on the radar since '05 and implemented at least initially by '06... exact date it was released from a stable branch I couldn't tell you, but it's been there a long while. ~brian
