[MacPorts] #29223: if an install is interrupted, a later install of the same package can fail if version number has since changed.
MacPorts
noreply at macports.org
Mon Apr 25 01:49:06 PDT 2011
#29223: if an install is interrupted, a later install of the same package can fail
if version number has since changed.
----------------------------------+-----------------------------------------
Reporter: rogerdpack@… | Owner: macports-tickets@…
Type: defect | Status: new
Priority: Normal | Milestone:
Component: base | Version: 1.9.2
Keywords: | Port:
----------------------------------+-----------------------------------------
Comment(by ryandesign@…):
Replying to [comment:9 raimue@…]:
> Replying to [comment:6 ryandesign@…]:
> > I think preserving mtimes is nice for other reasons, so I'd like to
find a fix that doesn't require us to destroy this piece of metadata.
> What other reasons do you refer to? We would still have the $Id$ line
indicating the time of commit at the top.
I just feel that it's a non-pointless piece of metadata and it would be
nice for us to not destroy it. It is nice to be able to look at a file in
a file browser and see when it was last modified, and to know that it was
actually modified by someone at that time, and not merely downloaded from
the rsync server.
The $Id$ line exists for Portfiles, but not necessarily for other files,
like those in the files directory. Portfiles don't necessarily have the Id
line either (or the svn:keywords property that keeps it updated), though
they should.
Conversely, while I support preserving mtimes, they are also unreliable
and might be destroyed by other processes (e.g. some kinds of backups...).
Therefore it would be great not to rely on them.
So while I wanted to begin by pointing out that the way we're handling
mtimes now is not sufficient for identifying a changed file, it is not
necessary either; a checksum is the correct way to solve this problem. I
don't see disadvantage to using a checksum; if you see any, please point
them out.
--
Ticket URL: <https://trac.macports.org/ticket/29223#comment:11>
MacPorts <http://www.macports.org/>
Ports system for Mac OS
More information about the macports-tickets
mailing list