[kwlug-disc] Presentation requests: package formats, repository best practices

[Doug Moen]

Hi Andrew.

One thing on my list is to build an AppImage binary of Curv for Linux, using github actions. That's a small, selfcontained project, if anyone is interested. There is already a github action for building Curv on Windows (not written by me) that you could look at for clues.

Another thing is to build an internet based package manager for Curv. I think it is better if this is a standalone project that is not tied to the Curv language. Call this project "gpkg" for concreteness. There is a command line tool, "gpkg", which interacts with a "*.gpkg" file, which describes a set of external package dependencies. Packages are git repositories, referenced using URLs. So it is decentralized, there isn't a central repository of all useful Curv code that somebody has to pay for and maintain. It would be loosely inspired by Go modules (https://golang.org/ref/mod) or Rust cargo files, and it would be language independent. I have not fully researched this idea or speced it out. Maybe the software I want already exists. Bonus if the code can be run inside a web browser (eg, it is written in a language that can be compiled into compact Web Assembly).

Doug Moen.

On Fri, Dec 18, 2020, at 8:47 PM, Andrew Sullivan Cant wrote:
> Doug,
> 
> Are you looking for any help with packaging? It sounds like you have
> challenges that could make an interesting group project.
> 
> Do you have any open issues or documentation about what you are already
> doing? Or what you want to be done?
> 
> Andrew
> 
> On 2020-12-16 2:43 p.m., Doug Moen wrote:
> > I am interested in the Snap vs AppImage vs Flatpak debate, since I have an open issue to provide Linux binaries for Curv. I've tried Snap and I consider it unacceptable (see the archives for details). My preference would be to ship a tar file containing an AppImage binary, plus directories containing examples and documentation. I already use AppImages of other open source tools. I don't know much about Flatpak, but it is not obvious you can ship text files with a flatpak install. Some of my users like the idea of snap or flatpak because it gives you a management interface for your installed software, with automatic update, which you would not get with appimage.
> > 
> > Some people want to install all their software from third party repositories, and don't want to get software directly from the producer. Chris Frey gives some reasons for this preference. That's fine for them, but there are millions of projects on github, and most of them are not packaged by Debian or Red Hat. I use niche software that may never be packaged like this, or if it is packaged at all, it is years out of date. So I need to get some of my software straight from github or the project website.
> > 
> > Chris mentions the argument that software in a 3rd party repository is more secure because the repository maintainers ensure that the dependencies are up to date with security updates. And static linking is bad. For my project, I've learned to statically link as many dependencies as possible, because the repo versions of some dependencies are so outdated that it won't work with my code. Or, the versions may be wildly different on Debian, vs Arch, vs whatever else (with incompatible APIs, even though it is the "same" library). I had a conversation with a repo maintainer who wanted to replace my static dependencies with dynamic ones, and oh by the way, my code won't compile when they do this. Curv is a hobby project and a research project: nobody is paying me to do that kind of work, so I don't do it. Dependency management in C++ is a special kind of hell, and I chose my development practices to minimize this pain. So definitely don't use Curv if this bothers you.
> > 
> > Doug Moen.
> > 
> > On Wed, Dec 16, 2020, at 4:06 AM, Paul Nijjar via kwlug-disc wrote:
> >> Here are two things I want to know about but do not want to present:
> >>
> >> - Snaps vs AppImage vs Flatpak vs ...
> >> There is some discussion here:
> >> http://kwlug.org/pipermail/kwlug-disc_kwlug.org/2020-June/019413.html
> >> but I do not have a good sense of what I should care about, and what
> >> (if any) of these formats is winning, and how easy/hard it is to
> >> package software for them.
> >>
> >> - Repository best practices: every programming language has its own
> >>   repository format. Archives like Debian or Ubuntu's seem to be
> >>   largely obsolete. 
> >>
> >>   Who is doing repositories right, in the sense that they curate good
> >>   software and have good governance? Who is doing it wrong? What are
> >>   the best practices?
> >>
> >> - Paul
> >>
> >>
> >> -- 
> >> Events: https://feeds.off-topic.kwlug.org 
> >> Blog: http://pnijjar.freeshell.org
> >>
> >> _______________________________________________
> >> kwlug-disc mailing list
> >> kwlug-disc at kwlug.org
> >> https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
> >>
> > 
> > _______________________________________________
> > kwlug-disc mailing list
> > kwlug-disc at kwlug.org
> > https://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
> > 
>