Post #3625652

@pwithnall@mastodon.social @bragefuglseth@sunny.garden Sorry for the super late comment, but: > Bazaar benefits from only having to deal with one backend (flatpak), which means its internals can be significantly simpler. Query results don’t have to wait for the slowest backend, or cater for different granularities of information provided by different backends. It also benefits from a lot of this code having been written and bugfixed already, over the years. 3/ While it is true that bazaar only has the one flatpak backend, I’ve made it a strict rule from the beginning that anything that has to do with with package management _must_ be invoked through the generic BzBackend interface, which the flatpak backend implements. And this pattern is seen elsewhere in the codebase. Generic structures have been maintained in as many places as possible to facilitate the creation of theoretical new backend. Alexander actually created a gnome shell extensions backend quite easily because he was able to reference the way flatpak objects were subclassed and adapt it to his needs This of course is not to say that bazaar doesn’t have it easier than gnome software, it most definitely does, but that considerable efforts have been made to make bazaar receptive to new backends as a fundamental design choice Of course, I referenced gnome software many many times in the early development of bazaar, so I simply wasn’t treading a new path like gs had to. It was the same language, same stack, same gui library, so bazaar owes a lot to gs and its iterative development from Phillip and others over the years. I think gnome software needs to be celebrated for forging the path rather than ridiculed. It had to cooperate with emerging technologies, and seeing how sporadic and unintuitive much of the Linux packaging landscape is to anyone with fresh eyes, it’s actually done an incredible job imo