[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))



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.


Reply to: