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

classic Classic list List threaded Threaded
103 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

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

Mo Zhou
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?

Best,
Mo.

Reply | Threaded
Open this post in threaded view
|

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

Andrey Rahmatullin-3
Isn't the Bikesheds initiative just this?

--
WBR, wRAR

signature.asc (911 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Ondřej Surý-4
In reply to this post by Mo Zhou
> Can we implement it?

Who is “we”? This is the usual problem with missing DPA/bikesheds/whatever, the most productive developer “Somebody” hasn’t joined Debian yet...

Ondrej
--
Ondřej Surý <[hidden email]>

> On 7 Apr 2019, at 15:26, Mo Zhou <[hidden email]> wrote:
>
> Can we implement it?

Reply | Threaded
Open this post in threaded view
|

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

Shengjing Zhu-3
In reply to this post by Mo Zhou
On Sun, Apr 7, 2019 at 9:26 PM Mo Zhou <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Peter Silva
In reply to this post by Mo Zhou
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 <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

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

Mo Zhou
In reply to this post by Andrey Rahmatullin-3
Hi,

This single sentence is quite ambiguous to non-native english speakers.

At the first glance I interpreted the sentence as
  "This will only lead to flamewars"
due to the meaning of bikeshed[1].

However, I got a hint from a fellow developer and learned that
"Bikeshed" has its own meaning under Debian's context, according
to some old mailing list fragments[2][3] -- which refers to a
dak feature (This is the first time I heard of such thing).

Do you mean I should stop and forget such thoughts, or just mean "This
is just the initiative of the 'Bikeshed' feature of dak"?

[1] https://www.urbandictionary.com/define.php?term=bikeshed
[2] https://lists.debian.org/debian-devel/2013/05/msg00131.html
[3] http://debian.2.n7.nabble.com/DAK-Commands-for-Bikesheds-td3650941.html

On Sun, Apr 07, 2019 at 06:32:37PM +0500, Andrey Rahmatullin wrote:
> Isn't the Bikesheds initiative just this?
>
> --
> WBR, wRAR

Reply | Threaded
Open this post in threaded view
|

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

Mo Zhou
In reply to this post by Shengjing Zhu-3
On Sun, Apr 07, 2019 at 10:05:35PM +0800, Shengjing Zhu wrote:
>
> Why not just start this as a personal project? And prove it works.

This is going to be a non-trivial initial work. On a non-business
and free-software basis, listen to the others first would be very
helpful. Positive feedbacks always help you strive forward on
volunteered works, right?

Reply | Threaded
Open this post in threaded view
|

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

Jonathan Carter (highvoltage)-2
In reply to this post by Mo Zhou
On 2019/04/07 15:26, Mo Zhou wrote:

> 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?

+1, it's a good idea and I've thought of it before as well.

Reading some of the initial replies to your post, it seems like people
don't entirely understand what you mean by an AUR-like service. This
would definitely be different than PPAs (in the launchpad sense) or
bikesheds (which is still a terrible name for all the confusion it causes).

Have you put any thought in possible implementation yet? I don't think
it's a good idea to devise any kind of new source packages. It's
probably not even necessary to use existing source packages. If you'd
have the standard debian packaging for such an AUR^W... DUR? in a git
repository (maybe like salsa.debian.org/dur/*) with a standardised git
workflow for these, then it should be rather trivial to implement with a
helper script that fetches the upstream source and just builds that
package locally. So I think from a technical point of view, implementing
something like AUR for Debian doesn't seem so hard. It can also act as a
nice gateway to proper Debian development.

-Jonathan

--
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Be Bold. Be brave. Debian has got your back.

Reply | Threaded
Open this post in threaded view
|

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

Mo Zhou
In reply to this post by Ondřej Surý-4
Hi,

The problem is not "who is responsible for implementing this", but "is
this valuable enough to implement".

If a group of people think it worthwhile to do something, they will be
glad to work together on a common belief, spontaneously.  I as the
initiator of the idea would definitely take action if I got enough
positive feedbacks.

On Sun, Apr 07, 2019 at 03:36:51PM +0200, Ondřej Surý wrote:

> > Can we implement it?
>
> Who is “we”? This is the usual problem with missing
> DPA/bikesheds/whatever, the most productive developer “Somebody”
> hasn’t joined Debian yet...
>
> Ondrej -- Ondřej Surý <[hidden email]>
>
> > On 7 Apr 2019, at 15:26, Mo Zhou <[hidden email]> wrote:
> >
> > Can we implement it?

Reply | Threaded
Open this post in threaded view
|

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

Adrian Bunk-3
In reply to this post by Mo Zhou
On Sun, Apr 07, 2019 at 01:26:12PM +0000, Mo Zhou wrote:

>...
> (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.

The requirements for distributing software in the system you want to
setup wouldn't be much different from what is required for non-free.

Anything that is legal to distribute can likely go into non-free.

>...
> (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).

Run-time autodetection is the best solution.

We also have packages that build several versions of a program,
with a tiny wrapper that selects the best at startup.

> 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?

You make it sound as if the number of packages would be what matters most.
Which is not true.

A low-popcon package that is old and stable and stale and doesn't depend
on changing libraries usually just continues working with close to zero
effort.

Most work is in the volatile areas of the archive, e.g. tensorflow as
one package might create more work than whatever you would consider
the saturation point for a single developer.

> Handing over some workload to the user community is not a bad thing,

"user community" sounds like a "somebody" that is in reality "nobody".

>...
> 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.
>...

Package installation runs as root, which means you are granting root
access to the package creator of every single package you are installing.

Be it malicious intention or just a packaging mistake,
trust and quality are not really optional items.

> Best,
> Mo.

cu
Adrian

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply | Threaded
Open this post in threaded view
|

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

Andrey Rahmatullin-3
In reply to this post by Mo Zhou
On Sun, Apr 07, 2019 at 02:17:00PM +0000, Mo Zhou wrote:
> However, I got a hint from a fellow developer and learned that
> "Bikeshed" has its own meaning under Debian's context, according
> to some old mailing list fragments[2][3] -- which refers to a
> dak feature (This is the first time I heard of such thing).
Yes, I've meant this thing.
As you can see, the idea is old, but the ideas are not enough.

--
WBR, wRAR

signature.asc (911 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

gregor herrmann-3
In reply to this post by Jonathan Carter (highvoltage)-2
On Sun, 07 Apr 2019 16:31:24 +0200, Jonathan Carter wrote:

> Reading some of the initial replies to your post, it seems like people
> don't entirely understand what you mean by an AUR-like service. This
> would definitely be different than PPAs (in the launchpad sense) or
> bikesheds (which is still a terrible name for all the confusion it causes).

I'm one of those people.
And I still don't know what "an AUR-like service" is, or what
"packaging scripts" are.

After reading the intro at
https://wiki.archlinux.org/index.php/Arch_User_Repository I guess,
translated to Debian terms, we are talking about user-provided source
packages?
 

Cheers,
gregor

--
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Furry Lewis: Billy lyons & stack o' lee

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Alf Gaida

On 07.04.19 17:40, gregor herrmann wrote:

> I'm one of those people.
> And I still don't know what "an AUR-like service" is, or what
> "packaging scripts" are.
>
> After reading the intro at
> https://wiki.archlinux.org/index.php/Arch_User_Repository I guess,
> translated to Debian terms, we are talking about user-provided source
> packages?
>  
>
> Cheers,
> gregor

Maybe a simple example of how things could work - the AUR consists of
several things

* the website https://aur.archlinux.org/
* the git repo
* some not official (and not really needed) helper scripts

The wiki put it in the best possible way:

> Users can search and download PKGBUILDs from the AUR Web Interface. These PKGBUILDs can be built into installable packages using makepkg, then installed using pacman.

Let's take lxqt-about as example: It is both in the regular archlinux
repository and in the AUR:

* https://www.archlinux.de/packages/community/x86_64/lxqt-about
* https://aur.archlinux.org/packages/lxqt-about-git/

So - what is the difference in this case: the community repository
points to the release, the AUR package points to git master. The
packaging consits only of the PKGBUILD aka the "build script". Thats all.

One can download these scripts and build  with a simple `makepkg`.
After building the package one can install the local packate with pacman:
* Repo: pacman -S lxqt-about
* local: pacman -U lxqt-about*tar.xz

And thats the whole magic - the only thing that the arch guys host is
the PKGBUILD, maybe some patches and install instructions. So they don't
have to care about any licensing or limitations - they only host the
receipe.

For debian it could work the same way - just host the debian dir and be
done with. Iirc the kde team work this way, they have only the debian
dir in salsa. With a modified watch file it should be possible to get
any source one want to. So the "only" thing needed is the infrastructure
to host and maintain these repos. The rest is up to the user and a
fundamental different approach as launchpad and ppa's.

Cheers Alf

PS: Please don't hit/yell at me if i've overly simplified some things. :)

Reply | Threaded
Open this post in threaded view
|

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

Roberto C. Sánchez-2
In reply to this post by Mo Zhou
On Sun, Apr 07, 2019 at 02:34:05PM +0000, Mo Zhou wrote:

> Hi,
>
> The problem is not "who is responsible for implementing this", but "is
> this valuable enough to implement".
>
> If a group of people think it worthwhile to do something, they will be
> glad to work together on a common belief, spontaneously.  I as the
> initiator of the idea would definitely take action if I got enough
> positive feedbacks.
>
I recommend that you start implementing something then request feedback.
Otherwise the whole exercise is just academic.

Regards,

-Roberto

--
Roberto C. Sánchez

Reply | Threaded
Open this post in threaded view
|

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

Roberto C. Sánchez-2
In reply to this post by Peter Silva
On Sun, Apr 07, 2019 at 10:13:58AM -0400, Peter Silva wrote:
>    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.)

There are many Debian developers who work as consultants specifically on
Debian-related work, either independently or as part of a company that
offers Debian-related services.

Since you have done most of the work, you could easily hire one of those
folks to help with a small number of hours worth of effort to take the
package through the process of getting it into Debian.

You can post to the debian-jobs list or check the Debian consultants
page on the main Debian website for candidates.

Regards,

-Roberto
--
Roberto C. Sánchez

Reply | Threaded
Open this post in threaded view
|

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

Phil Morrell
In reply to this post by Alf Gaida
On Sun, Apr 07, 2019 at 07:01:28PM +0200, Alf Gaida wrote:
> For debian it could work the same way - just host the debian dir and be done
> with. Iirc the kde team work this way, they have only the debian dir in
> salsa. With a modified watch file it should be possible to get any source
> one want to. So the "only" thing needed is the infrastructure to host and
> maintain these repos. The rest is up to the user and a fundamental different
> approach as launchpad and ppa's.

I like it, and just wanted to share this related idea from the Gentoo
world about bootstrapping some automated trust without increasing
contribution friction too much:

https://dev.gentoo.org/~mgorny/articles/guru-a-new-model-of-contributing-to-gentoo.html#user-access-and-workflow
--
Phil Morrell

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Peter Silva
In reply to this post by Roberto C. Sánchez-2


On Sun, Apr 7, 2019 at 1:27 PM Roberto C. Sánchez <[hidden email]> wrote:
On Sun, Apr 07, 2019 at 10:13:58AM -0400, Peter Silva wrote:
>    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.)

There are many Debian developers who work as consultants specifically on
Debian-related work, either independently or as part of a company that
offers Debian-related services.

Since you have done most of the work, you could easily hire one of those
folks to help with a small number of hours worth of effort to take the
package through the process of getting it into Debian.

You can post to the debian-jobs list or check the Debian consultants
page on the main Debian website for candidates.

Regards,

-Roberto
--
Roberto C. Sánchez


Hiring debian devs to get the packages into debian proper could make sense. One thing that dampens our enthusiasm for that at the moment is that our packages are still very unstable, in the sense that the we are releasing materially better version incrementally, say once or twice a month.  It is sort of analogous to a rolling release.  That works fine with the launchpad model, but if it gets baked into debian, then we need to support some random old version for many years. Perhaps once it has stabilized, that would be something we could work with, but for now, the launchpad.net model, which supports backporting seamlesslly and allows to support the same version on all distro versions, works better for us.  This is something a debian version of launchpad would get us.

 
Reply | Threaded
Open this post in threaded view
|

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

Roberto C. Sánchez-2
On Sun, Apr 07, 2019 at 05:50:37PM -0400, Peter Silva wrote:

>
>    Hiring debian devs to get the packages into debian proper could make
>    sense. One thing that dampens our enthusiasm for that at the moment is
>    that our packages are still very unstable, in the sense that the we are
>    releasing materially better version incrementally, say once or twice a
>    month.  It is sort of analogous to a rolling release.  That works fine
>    with the launchpad model, but if it gets baked into debian, then we need
>    to support some random old version for many years. Perhaps once it has
>    stabilized, that would be something we could work with, but for now, the
>    [2]launchpad.net model, which supports backporting seamlesslly and allows
>    to support the same version on all distro versions, works better for us. 
>    This is something a debian version of launchpad would get us.
>     

You can already accomplish what you are describing today:

- have packages uploaded to experimental
- upload to unstable and file a release critical bug to prevent it
  migrating to testing (look at https://bugs.debian.org/915050 for
  instance)

Both approaches get the package into Debian, available to users of
unstable and/or experimental, as appropriate, and without risk of the
package getting "baked in" to a Debian release for the long term.

Regards,

-Roberto

--
Roberto C. Sánchez

Reply | Threaded
Open this post in threaded view
|

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

Ben Finney-3
In reply to this post by Peter Silva
Peter Silva <[hidden email]> writes:

> One thing that dampens our enthusiasm for that at the moment is that
> our packages are still very unstable […], but if it gets baked into
> debian, then we need to support some random old version for many
> years.

By that description it is not a good candidate for putting into Debian
the operating system.

If the upstream project is not going to support specific releases for
years, that puts the onus on Debian package maintainers to choose a
version for support during the lifetime of a Debian release.

So would you agree, then, that the barrier to entry to the Debian system
is appropriate in this case?

--
 \      “I don't want to live peacefully with difficult realities, and |
  `\     I see no virtue in savoring excuses for avoiding a search for |
_o__)                        real answers.” —Paul Z. Myers, 2009-09-12 |
Ben Finney

Reply | Threaded
Open this post in threaded view
|

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

Peter Silva
In reply to this post by Roberto C. Sánchez-2


On Sun, Apr 7, 2019 at 8:41 PM Roberto C. Sánchez <[hidden email]> wrote:
On Sun, Apr 07, 2019 at 05:50:37PM -0400, Peter Silva wrote:
>
>    Hiring debian devs to get the packages into debian proper could make
>    sense. One thing that dampens our enthusiasm for that at the moment is
>    that our packages are still very unstable, in the sense that the we are
>    releasing materially better version incrementally, say once or twice a
>    month.  It is sort of analogous to a rolling release.  That works fine
>    with the launchpad model, but if it gets baked into debian, then we need
>    to support some random old version for many years. Perhaps once it has
>    stabilized, that would be something we could work with, but for now, the
>    [2]launchpad.net model, which supports backporting seamlesslly and allows
>    to support the same version on all distro versions, works better for us. 
>    This is something a debian version of launchpad would get us.
>     

You can already accomplish what you are describing today:

- have packages uploaded to experimental
- upload to unstable and file a release critical bug to prevent it
  migrating to testing (look at https://bugs.debian.org/915050 for
  instance)

Both approaches get the package into Debian, available to users of
unstable and/or experimental, as appropriate, and without risk of the
package getting "baked in" to a Debian release for the long term.

OK for unstable and testing, but I want to provide packages for stable versions of Debian using a separate repo that will be get frequent updates, even though the OS is stable. I get that with launchpad.net. Your proposal makes no version ever available for a stable version.  yes, it contradicts the meaning of stable, but the idea is similar to the idea of using snaps, where certain applications require current versions, while most of the OS remains a stable platform.  
1234 ... 6