fwiw, our organization doesn't have any debian devs. We have a few packages that we develop and deploy for our internal needs, and make available to the internet with public repositories. they are (perhaps not perfectly) debian compliant packages, but we aren't blessed debian devs (and frankly cannot be bothered to become them.) (fwiw: https://launchpad.net/~ssc-hpc-chp-spc/+archive/ubuntu/metpx-daily )
We have been publishing products on launchpad.net for years. We were able to do that relatively quickly. We would love to be able to upstream to debian, but haven't figured it out. There is a much higher barrier to entry. Our only option at the moment is likely suse build service, but we haven't bothered to figure that out either... We use ubuntu internally, and that's enough for internal use, so the others are nice to haves. for nearly anything on launchpad, it should be pretty straightforward for adapt to whatever gets done for debian. It also provides an intermediate on-ramp for gettting packages into Debian. as non-debian devs, something like launchpad looks useful to us. On Sun, Apr 7, 2019 at 9:54 AM Karsten Merker <mer...@debian.org> wrote: > 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. > > Regards, > Karsten > -- > Ich widerspreche hiermit ausdrücklich der Nutzung sowie der > Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung > sowie der Markt- oder Meinungsforschung. > >
