I also found these previous comments (by developers maybe?). They were phrased Rhetorically, as examples. However it feels constructive to actually try to answer them. To see what other work is required.
> The problem is all the other details that Zygmunt and Oliver mentioned,
Goto ---> Zygmunt comment #25
==============================
> [cleaned up] the bug we need to implement the epoch system first (for snapd) that doesn't understand this. This is the work that John referred to.
[RECAP] yes, that is definately a critical problem for lts releases
you said you are already working on it, thank you, very kind, it is the other bug elsewhere.
Goto ---> Oliver comment #26
=============================
Now this bit is rather repetitive...
But it's a case of trying to cover all the different angles / bases.
Without forgetting or ommiting anything (to not make another slip-up again).
Most times, the answer is the same (regardless). However sometimes it isn't.
> it is way more than a configuration dir, it is the fallback homedir for the snap if it does not use any interfaces, it is the place where downloads can end up without having to use any interfaces
Then the snap is not written very well.
Because it didn't implement interfaces (but needed to).
Anyhow, solved by my suggestion. Not a problem.
> and last but not least it is the default workdir that user started snap applications run in (vs $HOME which a non snapped app without security confinement would use, with access to all your sensible data)...
Then the snap is not written very well.
Because it didn't implement interfaces (but needed to).
Anyhow, solved by my suggestion. Not a problem.
> all these bits will be completely hidden once that dir moves
(so far!) Then the snap is not written very well.
Anyhow, solved by my suggestion. Not a problem.
> and we will have to explain to users that [something complicated]... or that the download they just did with that gui program ended up in a hidden space ...
Then the snap is not written very well.
Because it didn't implement interfaces (but needed to).
Anyhow, solved by my suggestion. Not a problem.
> while it might seem trivial to some to just move the dir name, there is a lot of conceptual work to be re-done and re-thought to not lose in security and usability when hiding it ...
(overall conclusion for those bits ^)
Either:
The snap is not written very well.
OR:
Solved by my suggestion. Not a problem.
================================================================================================
Suggestion was: 1 symlink + README.txt file. Can / does solve these above concerns for me ^^.
I also found these previous comments (by developers maybe?). They were phrased Rhetorically, as examples. However it feels constructive to actually try to answer them. To see what other work is required.
Goto ---> Jamie comment #29 ======= ======= =======
=======
> The problem is all the other details that Zygmunt and Oliver mentioned,
Goto ---> Zygmunt comment #25 ======= ======= ======= ==
=======
> [cleaned up] the bug we need to implement the epoch system first (for snapd) that doesn't understand this. This is the work that John referred to.
[RECAP] yes, that is definately a critical problem for lts releases
you said you are already working on it, thank you, very kind, it is the other bug elsewhere.
Goto ---> Oliver comment #26 ======= ======= ======= =
=======
Now this bit is rather repetitive...
But it's a case of trying to cover all the different angles / bases.
Without forgetting or ommiting anything (to not make another slip-up again).
Most times, the answer is the same (regardless). However sometimes it isn't.
> it is way more than a configuration dir, it is the fallback homedir for the snap if it does not use any interfaces, it is the place where downloads can end up without having to use any interfaces
Then the snap is not written very well.
Because it didn't implement interfaces (but needed to).
Anyhow, solved by my suggestion. Not a problem.
> and last but not least it is the default workdir that user started snap applications run in (vs $HOME which a non snapped app without security confinement would use, with access to all your sensible data)...
Then the snap is not written very well.
Because it didn't implement interfaces (but needed to).
Anyhow, solved by my suggestion. Not a problem.
> all these bits will be completely hidden once that dir moves
(so far!) Then the snap is not written very well.
Anyhow, solved by my suggestion. Not a problem.
> and we will have to explain to users that [something complicated]... or that the download they just did with that gui program ended up in a hidden space ...
Then the snap is not written very well.
Because it didn't implement interfaces (but needed to).
Anyhow, solved by my suggestion. Not a problem.
> while it might seem trivial to some to just move the dir name, there is a lot of conceptual work to be re-done and re-thought to not lose in security and usability when hiding it ...
(overall conclusion for those bits ^)
Either:
The snap is not written very well.
OR:
Solved by my suggestion. Not a problem.
======= ======= ======= ======= ======= ======= ======= ======= ======= ======= ======= ======= ======= =====
Suggestion was: 1 symlink + README.txt file. Can / does solve these above concerns for me ^^.