> 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 `fla

> 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.