The intent of assumes features was to try not to overuse, because it
becomes hard to use and hard to maintain. The ideal candidate for a custom
entry on assumes are those features that can exist in one distribution but
not the other, due to constraints which are unrelated to it being merely an
old
On 19/02/17 12:07, Joseph Rushton Wakeling wrote:
> This would be super-useful. Conversely, to what extent might it be
> possible to guide the package developer to a clear understanding of
> what capabilities a particular snap package assumes?
Hmm... that's a Turing-complete problem :)
However,
On 19/02/17 15:26, Sergio Schvezov wrote:
It was my intention to fully document this. I just did half of the job as I
only added information about it under the python plugin update. Sorry about
this. I have updated the release notes[1] so the next person doesn't fall into
this time sync trap!
On Sun, 19 Feb 2017 13:07:48 +0100, Joseph Rushton Wakeling wrote:
> On 19/02/17 12:21, Mark Shuttleworth wrote:
>> Step 4, announce new capabilities on the list
>>
>> In many cases, the existence of a new capability is meaningful for a
>> large number of snapcrafters, lets share the beta documenta
On 19/02/17 12:21, Mark Shuttleworth wrote:
We have a nice mechanism to ensure that snaps which use newer
capabilities don't end up on systems with older snapd's that don't
support those capabilities, which is the 'assumes' keyword. This email
is a proposal to make that usable.
This would be su
