Snapcraft's state tracking improvements

[Sergio Schvezov]

El 14/12/16 a las 03:02, Didier Roche escribió:
> Le 13/12/2016 à 22:57, Kyle Fazzari a écrit :
>> Hey everyone.
> Hey Kyle
>> I feel it coming on... this is going to be a tome. tl;dr... snapcraft
>> could be smarter than it is. But would that lead to its doing more for
>> you than you want? We'd like to find out.
>>
>> I've spoken to a few of you individually about this, and I want to open
>> this topic up for wider conversation. We have a number of bugs logged
>> against snapcraft for its state tracking shortcomings. For example, a
>> few of you may have run into these issues:
>>
>> - You add a stage package to a part in an already-built snap, and run
>> `snapcraft` again. It happily says all the steps have already run, and
>> generates a snap that doesn't contain your stage package.
>>
>> - You add (or modify) a file in the local source for a part of an
>> already-built snap, and run `snapcraft` again`. It again reports that
>> everything has already run, and generates a snap that doesn't contain
>> your modifications.
> There is another one: there is a remote source which changes. I think
> snapcraft can be smarter about that and store the hash of the git/bzr
> commit id, and check if new remote hash is the same or not. This is a
> little bit more problematic for other kind of assets like tarballs, as
> you can only create and check a checksum (if not published) after
> downloading… defeating the caching purpose :)

For remote sources, I would only do this on an explicit (re)pull. We 
don't want to talk to the network (unless a plugin is wired to do so 
where we strive not to) unless the user really wants to.