On Sun, Apr 7, 2019 at 9:26 PM Mo Zhou <lu...@debian.org> wrote: > > Hi folks, > > 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. > > (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. > > (4) Packages with dirty hacks, or targeted on testing the water. This > makes sense for packages that doesn't worth the effort to make it fully > compliant with Debian's quality requirement and some user just wants it. > > (5) Packages that utilizes SIMD instructions heavily. Such package is > very easy to package in such repo. (So this Proposal actually suppresses > and replaces my SIMDebian project). > > 2. Allows us to offload some low-popcon, or QA-questionable packages > from the archive. Debian's archive size is continuously increasing, but > the number of Debian Developers has been staying around 1000 for many > many years. Saturation will definitely happen in the future if we do > nothing to change - or saturation has already happended. An Archlinux > Developer's saturation point may be several thousand (See Felix Yan, an > Arch Dev), but a Debian Developer often saturate at, maybe 30~100? > Handing over some workload to the user community is not a bad thing, > especially for the cold packages. > > 3. Allows us to accept potential contributors friendly, and possibly > form a new user community. The high quality standard of Debian may scare > some potential contributors away. In the informal packaging area, it's > easier for people to contribute. Look at AUR and Archlinux Trusted Users > as example. Of course, we can promote high quality creations from users > into debian archive. > > Just a few of my naive thoughts. If this idea came true, I'll > denfinitely be able to continue with TensorFlow and PyTorch packaging, > at an significantly lower cost. I'm also happy to throw some of my > low-popcon packages to this area, so I can focus on more valuable ones. > This idea really excites me. Can we implement it? >
Why not just start this as a personal project? And prove it works. -- Shengjing Zhu
