Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))
- Date: Thu, 11 Apr 2019 09:26:15 +0100
- From: Simon McVittie <smcv@xxxxxxxxxx>
- Subject: Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))
On Thu, 11 Apr 2019 at 07:44:30 +0000, Mo Zhou wrote:
> On Wed, Apr 10, 2019 at 04:56:51PM +0200, Helmut Grohne wrote:
> > It seems that a key aspect of this thing is avoiding to (re)distribute
> > sources.
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.
Some key differences:
* game-data-packager recipes are part of its source code. Each version
uploaded to Debian contrib supports a fixed set of games.
* game-data-packager normally only has a trivial "compilation" step,
although for Quake II expansions (what we'd now call DLC) it does need to
compile C code.
* game-data-packager doesn't expect users to review the recipes that build
its packages. They're reviewed by a DD (in practice, me) before entering
a release. For games that contain executable code (Quake II expansions),
I also review the changes to that executable code whenever I update to a
* game-data-packager has this design principle: if a component can have
bugs, and they are bugs that Debian can (technically and legally)
fix, then we try to put that component in the Debian contrib apt
archive, not in the game-data-packager-produced .deb. For example,
quake3.desktop and unreal.desktop can easily have bugs (missing
translations or Keywords or similar), and they were written by Debian
contributors under a Free Software license, so we put them in quake3.deb
and game-data-packager-runtime.deb (respectively) in the Debian contrib
apt archive, not in the quake3-data.deb and unreal-gold.deb produced
* game-data-packager recipes are declarative (YAML) and don't attempt to
be compatible with the full generality of Debian packaging. Individual
games can have "plugins" to provide imperative build/packaging steps,
but those are part of game-data-packager's source code.
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.
> 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 don't think I would start using such a user repository. I'm much too
> > scared about it.
> Understand. The nature of AUR is similar: every user is recommened to
> review the code before execution to confirm safety.
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