2 ms·
If building it from source is acceptable, why would using packages direct from the maintainers not be? For anything in an interpreted language, there's little d
by takluyver 11y ago
If building it from source is acceptable, why would using packages direct from the maintainers not be? For anything in an interpreted language, there's little difference anyway.
I agree that Debian is too accepting of packages. We don't recommend that anyone installs Jupyter/IPython with apt, and I wouldn't mind if Debian removed it from the repos. But if there are all these packages that shouldn't be distributed through Debian, we need some other way for users to get them conveniently. We often use language package managers like pip, but they're not great for desktop applications - they can't easily set up a launcher entry, for instance. That's where something like AppImage comes in.
- jessaustin 11y agoI think it's perfectly acceptable for project maintainers to provide rpms, debs, ppas, etc. as long as those artifacts are organized in largely the same way that distro maintainers would organize them. (I doubt any distro maintainers would disagree.) I don't think it's a good idea to pack lots of already-distro-packaged libraries into those artifacts. Building for many distro formats is a pain, but I doubt that building this new format in a universal way will be easy either. If you have a different AppImage for each distro/version combo, is that an improvement? For the packages you've mentioned, live active projects with maintainers who can produce this distribution format but can't deal with apt, maybe the giant ball of wax is okay. I won't be installing anything this way, but clearly I'm not the target user. It seems certain, however, that in future we'll be hearing about lots of vulnerabilities attributed to AppImages linking in old library versions.