4 ms·

You do not need that, you can just use a flag snap install --dangerous /path/to/snap

by simion314 6y ago

pantalaimon 6y ago
But then you won’t get updates for that Snap
- simion314 6y ago
  So you want something like a PPA? Is flatpack promoting each app will have it's own repo(Skype.Dropbox,Slack,Discord?) Seems to me that you want a way to have applications and updates installed by people and bypass the review process? If you are a distro maintainer you can change the hardcoded values before you build(distros always change this stuff) but if you are not a distro then you should either submit the app for review or do what other apps do and prompt a notification that a new update is available with a link to a download page.
  - vetinari 6y ago
    > Is flatpack promoting each app will have it's own repo(Skype.Dropbox,Slack,Discord?) Flatpak CAN support the scenario, where each app can have it's own repo. It's an option, not forced down your throat. Or you can self-host your private repo (e.g. applications used inside your network) IN ADDITION to public repos. > Seems to me that you want a way to have applications and updates installed by people and bypass the review process? Yes, I want to have Canonical out of the way. They can have their own repo if they really want; those who want curation by Canonical are free to use it. But I want to have options of different repos, with different curators. Canonical doesn't deserve to be the single gatekeeper between me and the apps. > If you are a distro maintainer you can change the hardcoded values before you build(distros always change this stuff) but if you are not a distro then you should either submit the app for review or do what other apps do and prompt a notification that a new update is available with a link to a download page. And this attitude is going to be a major reason why most distributions and users won't adopt snap. It will die the same way as other Canonical dead-ends did, while damaging the Linux ecosystems for a few years.
    - simion314 6y ago
      if you are a user then you use a distribution, say Debian,Arch. This distro could setup whatever store, repo and keys they want and Canonical is not forcing themselves on other distributions (it is not systemd). I am looking at this from a dev point of view, you are asking to prioritize a feature that almost nobody will use over other high priority tasks. The article mentions Canonical did this mistake in the past with Launchpad and it was for nothing. The store code seems to be a mess and you can't just drop the code and GitHub and you are done, it is a lot of work to refactor the code. Same for the client, it is a of work to correctly add the feature to support multiple repositories, if it was only 1 day work somebody would have forked the client, patch it and published it already. After you work as a developer and see many bugs or problems you look at things differently, for example as a dev I could allow access to an advanced feature in my app, it seems to be just a few lines of extra code. But the reality is that this costs more - maintenance cost as the software evolves and things under the hood change - this new feature needs to be documented, someone needs to write documentation, maybe record videos so the minimum number of people contacts support for help - people don't read documentation so people will contact support and complain that the feature is not working as they expected or that is should have more X or Y - since is an advanced feature some people might break their stuff and then complain and make a lot of noise and as a dev I need to go and add many checks in the code to prevent people breaking their shit.
      - vetinari 6y ago
        > This distro could setup whatever store, repo and keys But only one. And changing it is a matter of replacing binary/entire package. If is a far cry from `flatpak remote-add $url`. > Canonical is not forcing themselves on other distributions (it is not systemd) Systemd did not force itself on distribution either. Systemd was solving real problems distributions had, and others were ignoring them. Including Upstart, which only made it worse. It's not like systemd had easy start. Even Redhat's management didn't see the point (Lennart P. couldn't work on it during his working hours). It took adoption by Arch to change Redhat's position. > I am looking at this from a dev point of view, you are asking to prioritize a feature that almost nobody will use over other high priority tasks. How do you know? Did you do any research among users, or it is just against Canonical modus operandi, where they try to insert themselves as gatekeeper in some layer of Linux community and be the single entity that can be approached for a given topic? For many, it has much higher priority than forced updates, enforcing a single signing key or paid custom stores for FOSS. > The article mentions The article does not make honest arguments, it often misdirects. It is an apologia piece. > Canonical did this mistake in the past with Launchpad and it was for nothing Canonical did many more, more serious mistakes with Launchpad. Yes, PPAs were a dead-end, but for other reasons, that are for a separate debate. > The store code seems to be a mess and you can't just drop the code and GitHub and you are done, it is a lot of work to refactor the code. The code is a mess from the start. Somebody didn't do their homework what their users will be interested in, but only what they are interested in (see gatekeeping above). > Same for the client, it is a of work to correctly add the feature to support multiple repositories, if it was only 1 day work somebody would have forked the client, patch it and published it already. On the client we can see that they tried to do MVP, be first on "the market" and capture it. It is full of user visible annoyances that are not going to be solved (polluting mount namespace, visible snap dir in user homedir, no dedup, etc). They did quick and dirty job to be first, instead of doing it properly, like the Flatpak guys did. > But the reality is that this costs more So drop the things that make it complicated, such as routing separate stores through Canonical... The reality is, that this is just an excuse to do what Canonical wants, not what their users want.

You do not need that, you can just use a flag snap install --dangerous /path/to/snap

pantalaimon 6y ago

But then you won’t get updates for that Snap

simion314 6y ago
So you want something like a PPA? Is flatpack promoting each app will have it's own repo(Skype.Dropbox,Slack,Discord?) Seems to me that you want a way to have applications and updates installed by people and bypass the review process? If you are a distro maintainer you can change the hardcoded values before you build(distros always change this stuff) but if you are not a distro then you should either submit the app for review or do what other apps do and prompt a notification that a new update is available with a link to a download page.
- vetinari 6y ago
  > Is flatpack promoting each app will have it's own repo(Skype.Dropbox,Slack,Discord?) Flatpak CAN support the scenario, where each app can have it's own repo. It's an option, not forced down your throat. Or you can self-host your private repo (e.g. applications used inside your network) IN ADDITION to public repos. > Seems to me that you want a way to have applications and updates installed by people and bypass the review process? Yes, I want to have Canonical out of the way. They can have their own repo if they really want; those who want curation by Canonical are free to use it. But I want to have options of different repos, with different curators. Canonical doesn't deserve to be the single gatekeeper between me and the apps. > If you are a distro maintainer you can change the hardcoded values before you build(distros always change this stuff) but if you are not a distro then you should either submit the app for review or do what other apps do and prompt a notification that a new update is available with a link to a download page. And this attitude is going to be a major reason why most distributions and users won't adopt snap. It will die the same way as other Canonical dead-ends did, while damaging the Linux ecosystems for a few years.
  - simion314 6y ago
    if you are a user then you use a distribution, say Debian,Arch. This distro could setup whatever store, repo and keys they want and Canonical is not forcing themselves on other distributions (it is not systemd). I am looking at this from a dev point of view, you are asking to prioritize a feature that almost nobody will use over other high priority tasks. The article mentions Canonical did this mistake in the past with Launchpad and it was for nothing. The store code seems to be a mess and you can't just drop the code and GitHub and you are done, it is a lot of work to refactor the code. Same for the client, it is a of work to correctly add the feature to support multiple repositories, if it was only 1 day work somebody would have forked the client, patch it and published it already. After you work as a developer and see many bugs or problems you look at things differently, for example as a dev I could allow access to an advanced feature in my app, it seems to be just a few lines of extra code. But the reality is that this costs more - maintenance cost as the software evolves and things under the hood change - this new feature needs to be documented, someone needs to write documentation, maybe record videos so the minimum number of people contacts support for help - people don't read documentation so people will contact support and complain that the feature is not working as they expected or that is should have more X or Y - since is an advanced feature some people might break their stuff and then complain and make a lot of noise and as a dev I need to go and add many checks in the code to prevent people breaking their shit.
    - vetinari 6y ago
      > This distro could setup whatever store, repo and keys But only one. And changing it is a matter of replacing binary/entire package. If is a far cry from `flatpak remote-add $url`. > Canonical is not forcing themselves on other distributions (it is not systemd) Systemd did not force itself on distribution either. Systemd was solving real problems distributions had, and others were ignoring them. Including Upstart, which only made it worse. It's not like systemd had easy start. Even Redhat's management didn't see the point (Lennart P. couldn't work on it during his working hours). It took adoption by Arch to change Redhat's position. > I am looking at this from a dev point of view, you are asking to prioritize a feature that almost nobody will use over other high priority tasks. How do you know? Did you do any research among users, or it is just against Canonical modus operandi, where they try to insert themselves as gatekeeper in some layer of Linux community and be the single entity that can be approached for a given topic? For many, it has much higher priority than forced updates, enforcing a single signing key or paid custom stores for FOSS. > The article mentions The article does not make honest arguments, it often misdirects. It is an apologia piece. > Canonical did this mistake in the past with Launchpad and it was for nothing Canonical did many more, more serious mistakes with Launchpad. Yes, PPAs were a dead-end, but for other reasons, that are for a separate debate. > The store code seems to be a mess and you can't just drop the code and GitHub and you are done, it is a lot of work to refactor the code. The code is a mess from the start. Somebody didn't do their homework what their users will be interested in, but only what they are interested in (see gatekeeping above). > Same for the client, it is a of work to correctly add the feature to support multiple repositories, if it was only 1 day work somebody would have forked the client, patch it and published it already. On the client we can see that they tried to do MVP, be first on "the market" and capture it. It is full of user visible annoyances that are not going to be solved (polluting mount namespace, visible snap dir in user homedir, no dedup, etc). They did quick and dirty job to be first, instead of doing it properly, like the Flatpak guys did. > But the reality is that this costs more So drop the things that make it complicated, such as routing separate stores through Canonical... The reality is, that this is just an excuse to do what Canonical wants, not what their users want.