Instead, the Qt5 binaries should be provided as an independent, shared snap that gets dynamically loaded with our application’s snap. For example, our application uses Qt5 which causes the snap size to bloat up to 70 MB. Īs far as snaps themselves, I wish they were built more like docker containers where different layers could be combined dynamically to provide the final product. It is currently a little confusing on how to get to where your current snaps are. How would you improve the snap system?įirst I would make it easier to navigate around the developer section of the ubuntu store. Most of the issues we have run into involve theming, plugs, and keyboard shortcuts. Snap users easily find us on Github and provide feedback on their experience. Packaging as a snap also removes the dependency nightmare of different Linux distributions. Our users are able to discover, download, and use our app in a matter of seconds through the Ubuntu store. How do you think packaging KeePassXC as a snap helps your users? Did you get any feedback from them? Not at this time, but if I ever publish another cross-platform tool, I will certainly use the ubuntu store and snap builds. Is there any other software you develop that might also become available as a Snap in the future? We use the stable channel for milestone releases and the edge channel for intermediate builds (nightlies). What release channels (edge/beta/candidate/stable) in the store are you using or plan to use? It is a critical tool for our distribution with over 18,000 downloads in less than 4 months! The store also ensures users have the latest version and it is always guaranteed to work on their system. Yes, we use the snap store exclusively for our deployment. Do you currently use the snap store as a way of distributing your software? How do you see the store changing the way users find and install your software? Now we can publish snaps immediately upon completion of a milestone, or even intermediate builds for develop. With the introduction of, the integration with our workflow has improved greatly. The easiest part was publishing the snap for public consumption, that took a matter of minutes. It only took a couple of iterations before a successful snap was built and tested locally. At the time, the documentation did not provide many full-text examples of different build patterns. The initial build of the snapcraft.yaml file was a bit rough. How does building snaps compare to other forms of packaging you produce? How easy was it to integrate with your existing infrastructure and process? It also meant we could bypass the lengthy review and approval process of the official apt repository. The novelty of bundling an application and deploying it to the Ubuntu Store, for free, was really attractive. What was the appeal of snaps that made you decide to invest in them? We deployed our first snap version of the app in January 2017. Since then I dove into the world of building and deploying snaps through the KeePassXC application. I learned about snaps through an article on Ars Technica about a year ago. Some of the major features that we have already shipped are browser integration, YubiKey authentication, and a redesigned interface. Our main goal is to incorporate the features that the community wants while balancing portability, speed, and ease of use. We are an active open source project that is available on all Linux distributions, Windows XP to 10, and Macintosh OSX. KeePassXC, for KeePass Cross-Platform Community Edition, is an extension of the KeePassX password manager project that incorporates major feature requests and bug fixes. If you would like to contribute a guest post, please contact. This is a guest post by Jonathan White (find him on Github) one of the developers behind keepassxc.
0 Comments
Leave a Reply. |