Web lists-archives.com

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

On Sun, Apr 07, 2019 at 01:26:12PM +0000, Mo Zhou wrote:

> The absense of a centralized, informal Debian package repository where
> trusted users could upload their own packaging scripts has been
> long-forgotten. As an inevitable result, many user packaging scripts
> exist in the wild, scattered like stars in the sky, with varied
> packaging quality. Their existence reflects our users' demand,
> especially the experienced ones', that has not been satisfied by the
> Debian archive. Such idea about informal packaging repository has been
> demonstrated successful by the Archlinux User Repository (AUR). Hence,
> it should be valuable to think about it for Debian.
> Assume that Debian has an informal packaging repository similar to AUR,
> which distrbutes packaging scripts only and requires to be built
> locally. According to my observation and experience, such a repository:
> 1. Allows packaging in some compromised manner to exist, which means
> they dont fully comply with DFSG or Policy. This makes great sense for
> several kinds of packages:
> (1) Packages that are extremely hard to made compliant to Policy. For
> example, bazel the build system of TensorFlow and other Google products
> - No Debian Developer can make it meet the Policy's requirement without
> great sacrifice. The outcome doesn't worth the waste in time and energy.

This is something that would probably be acceptable to me on
Debian-hosted infrastructure, but ...

> (2) Dirty but useful non-free blobs, such as nvidia's cuDNN (CUDA Deep
> Neural Network) library, which dominates the field of high performance
> neural network training and inference. I really hate reading NVIDIA's
> non-free legal texts, and in such repository we can avoid reading the
> license and just get the scutwork done and make users happy.
> (3) Data with obscure licensing. In this repository we can feel free to
> package pre-trained neural networks or training data without carefully
> examing the licensing.

... this is something that I personally have a big problem with
because it would set a precedent that I don't want the Debian
project to set.  We as a project host a non-free repository
(which is fine for me), but before we take packages into
non-free, we put a lot of effort into checking the licenses for
problems (besides them being non-free).  Hosting a repository on
Debian infrastructure that effectively states "we don't care for
any license terms" is a no-go for me, even if it contains only
packaging scripts and not the actual non-free components.

Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.