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

[Andrew Sullivan Cant]

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
>