Hi, On Thu, Apr 11, 2019 at 09:26:15AM +0100, Simon McVittie wrote: > On Thu, 11 Apr 2019 at 07:44:30 +0000, Mo Zhou wrote: > It might be interesting to look at game-data-packager, which is another > tool that builds and optionally installs .deb files for data that is > not suitable for the Debian archive (in most cases not even for non-free), > without going via a .dsc or source package.
Any link please? Both apt-file-search and google found nothing. > If I had enough free time, my long-term plan for g-d-p is to make > it optionally produce Flatpak apps or extensions (based on either > the reference "freedesktop" runtimes available on Flathub, or a new > Debian-provided runtime) instead of .deb files, to make it easier to run > its supported games in a sandbox to mitigate any security vulnerabilities > that they might have. > > I can't help thinking that a sandboxed app system like Flatpak or Snap > would be a better fit than .deb for leaf packages that have had minimal > or no review and don't really need to be part of the operating system. > For various reasons my preference is Flatpak (obviously, I wouldn't > maintain it otherwise) but I'm sure that proponents of Snap would tell > you that it should also be a candidate. I don't have experience with Flatpak/Snap. However sandboxing sounds great. Is there any existing work that helps one convert existing .deb into flatpack/snap format? I'd be glad to enable DUPR build Flatpack/Snap packages in the future, if possible. > > afterall the .durpkg header is a shell script > > I'm sure the costs and benefits are different for your use case, but as > a data point: game-data-packager used to have an ad-hoc shell script per > supported game. It has been *much* nicer to maintain since its redesign > as a Python program that reads declarative recipes. I've ever thought about providing a Python interface in duprkit, such that a .durpkg can be either (shell script) + (HFT part) or (python script) + (HFT part) I hesitate to move forward on that direction because not everybody can write python; but everyone who types commands in the terminal can write basic shell. > What proportion of AUR users do you think genuinely do this? > > What proportion of AUR users do you think are sufficiently experienced > to be able to recognise malicious code in a packaging recipe or an > upstream release? TBH IDK. Umm... At least I'm not blindly accepting PRs to the DefaultCollection.
