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.
--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
