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

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

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

Mo Zhou
On Mon, Apr 08, 2019 at 03:50:19PM +0300, Tzafrir Cohen wrote:
> Hi,
>
> The README states a directory structure with a top-level collection
> directory, but the repository currently does not include one.

The github.com:dupr/DefaultCollection.git repo is indeed a specification
compliant if you mangle the first layer of directory structure.

```
--- a/README
+++ b/README
@@ -17,7 +17,7 @@ name. Plus, no one prevents you from submitting a debian directory.

 For example:

-A-Certain-Collection/
+A-Certain-Collection/  # For example, this git repository.
     library-foo/
         library-foo.durpkg
         library-foo-ubuntu.durpkg
```

> Looking at:
>
>
> https://github.com/dupr/DefaultCollection/blob/master/rover/rover.durpkg
>
> I see that the name of the directory repeats quite a number of times.
> The clean function needs to state 'rm -rf' explicitly, which I hope
> won't lead to typos.

The repetition of "pushd" and "popd" is something that could be improved
later. So the same as the 'rm -rf' hook. The two problems have been
tracked here:
https://github.com/dupr/duprkit/issues/3
https://github.com/dupr/duprkit/issues/4

Please don't expect too much from a prototype rushed within several
hours. That's used for presenting the idea instead of presenting
a graceful implementation.

> The changelog is buried deep inside the package an needs to be updated
> whenever a version number is bumped.

AUR's PKGBUILD doesn't record changes. If you feel like that the dch
has been deeply buried, the usage of traditional debian/ directory
layout is still supported:
https://github.com/dupr/DefaultCollection/tree/master/rover-traditional
https://github.com/dupr/DefaultCollection/blob/master/rover-traditional/debian/changelog

One could easity convert the packaging between single-file format and
debian/ directory with a single-command-cost (virtually zero-cost).

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 W. Martin Borgert
Hi,

On Mon, Apr 08, 2019 at 01:59:04PM +0200, W. Martin Borgert wrote:
> Quoting Mo Zhou <[hidden email]>:
> > Plus, letting users write PKGBUILD doesn't help them learn
> > Debian packaging at all...
>
> Then I would try to diverge as little as possible
> from the classical way how Debian packaging works.
 
If you didn't read the code of fold/unfold and don't understand
why I declare that the cost of the proposed single-file format
has nearly zero-cost, please refer to the traditional style
alternative:

https://github.com/dupr/DefaultCollection/tree/master/rover-traditional
I expect no one to argue about this "traditional" style.
This "traditional" style is exactly what you do for the
official debian development, in the "debian-directory-only"
git workflow.

Reply | Threaded
Open this post in threaded view
|

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

Jonathan Dowland
In reply to this post by Mo Zhou
On Mon, Apr 08, 2019 at 11:18:14AM +0000, Mo Zhou wrote:
>The proposed idea is source-only-based, and is totally different
>from PPA (source+binary-based). I'm a PPA user and I don't have
>any reason to re-invent yet another PPA.

Sorry I appreciate that *your* idea is different, and effectively
my sub-thread is a hijack, but to be clear what I was referring to
was the naming of the pre-existing "Bikeshed" proposal for Debian,
which is equivalent to PPAs.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

Reply | Threaded
Open this post in threaded view
|

Re: duprkit User Repository

Roberto C. Sánchez-2
In reply to this post by Mo Zhou
On Mon, Apr 08, 2019 at 12:57:56PM +0000, Mo Zhou wrote:

> On Mon, Apr 08, 2019 at 08:36:45AM -0400, Roberto C. Sánchez wrote:
> > On Mon, Apr 08, 2019 at 11:02:35AM +0000, Mo Zhou wrote:
> > In such a large community of volunteers it may not be enough to propose
> > something that is only marginally better because the cost (even just in
> > cognitive terms) and effort required for so many individuals to overcome
> > inertia is relatively high.
>
> Linus said that "Talk is cheap, show me the code."
> Now I have shown the code and nobody read that.
>
> The single-file format is not mandatory, and two convertion tools
> enables zero-cost convertion:
> https://github.com/dupr/duprkit/blob/master/bin/fold
> https://github.com/dupr/duprkit/blob/master/bin/unfold
>
> And the prototype implementation is compatible to the traditional debian/
> directory. See https://github.com/dupr/DefaultCollection/tree/master/rover-traditional
> for the example.
>
> BOTH single-file format and traditional format are supported. People
> could choose and use what they like.
>
> I admit that I'm quite fond of the proposed single-file format, and
> hence didn't mention and compatiblity with traditional format in design.
>  
> > I am not trying to discourage you from your effort, but rather advising
> > you that the chances of success would improve if you address the
> > principal obstacles to adoption in a holistic way.  (As I already
> > pointed out, your current approach misses a great deal.)
>
> What else can I do? Both traditional and single-file formats  are
> explicitly supported now.
>

Two suggestions:

- Stop claiming that what you propose is "zero-cost", "only 1 second of
  work", etc.*
- Find the individuals who currently experience the greatest pain
  associated with the problem you are trying to solve and whose pain is
  relieved by your solution.  Get them to adopt it.  If it works as well
  as you say it does, they will be enthusiastic adopters and will have
  no problem telling others, in concrete terms, how much better your
  solution is than whatever the current situation is.

* Even in a perfect world, nothing is "zero-cost."  To a community of
  contributors whose purpose it is to build an operating system
  distribution a deep understanding of the components that compose the
  system and the components used to build the system are effectively a
  requirement.  Thus, if I came along and said, "here, I have a drop-in
  replacement for utility 'foo', and I call the replacement 'bar', and
  it supports all the same options as 'foo' so that you can use it
  without having to think about any differences" I would still expect
  that there would be a need for me to convince potential adopters that
  things really work that way.  Experience tells us that even "drop in"
  replacements for things are seldom that "perfect" when it comes to
  compatibility with whatever they are replacing.

Regards,

-Roberto
--
Roberto C. Sánchez

Reply | Threaded
Open this post in threaded view
|

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

Alf Gaida
In reply to this post by Ondřej Surý-4
DUR is fine, DPA is fine PPA is not - as it is used before in a totally
different context.

The idea just to require git is really nice, putting all the things into
a single file is not. Not even Arch does it. (patches, install, config
...) - so the default debian dir should be enough.

Please think a bit further - which files are really needed?
* control
* rules
* watch

There was discussions to make rules obsolete in standard packages - if
there is no rules file, just assume/use the default. compat is obsoleted
if one use debhelper-compat, copyright would be nice to have, but might
not be needed for a possible dur. Same for all other things.

Things become a bit different if one want to use patches. So why don't
use the debian standards. Same for packages that result in more than one
binary package.

If anything else fails just add a file with a special set of things for
the DUR/DPA - should be dead easy, i use something similar for years now
to build things from several git sources.

Cheers Alf

Reply | Threaded
Open this post in threaded view
|

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

Kyle Edwards
In reply to this post by Peter Silva
On Mon, 2019-04-08 at 00:02 -0400, Peter Silva wrote:
If one needs to keep a close eye on changes to make sure they can still
be installed even on a years-old OS, the resulting packages can be
placed in a custom repository set up with the instructions at
<URL:https://wiki.debian.org/DebianRepository/Setup>. What am I missing?


yes, it can be done, but it is a lot more work for individual packagers.

launchpad.net combines:
   - very few clicks to build custom repositories.
   - a build environment for each OS, so that it runs "debuild" in the currently patched version of the OS for which the package it built.

It saves people from having to build their own custom repository, and from having to maintain a build environment for all supported OS versions and architectures.  on Ubuntu,  packages are built for 14.04, 16,04, 18.04, 18.10, 19.04, and I get all those just from clicking one box for each one. I think it also propagates re-building of packages when a build-dependency changes, without my knowledge or interaction.  It leverages the ubuntu build-farm for third-party packages.

With debian, it's kind of all or nothing.  Etiher you're in Debian, and it gets built on every platform using the build farm, or it's not, so you get no help at all. Launchpad gives a nice middle road that suits us right now, and if something similar were available for debian, it would provide a stepping stone to being in Debian proper.

CMake and VTK upstream here. This was my exact observation a while back when I tried to package VTK for Debian and Ubuntu. Packaging for Ubuntu was very easy: just upload your packaging script to launchpad.net and you're done. For Debian, I had to set up a build machine and an Aptly repository on a virtual machine that pulls in built packages from "incoming", inserts them into the Aptly repo, and rsyncs them to a web server, basically mimicking what the Debian repo infrastructure does. This was non-trivial to set up, and I found it frustrating that Launchpad-like infrastructure did not exist for Debian. (Building lots of packages is easy once you have the infrastructure, but the initial investment is rather high.) Just my $0.02.

Kyle
Reply | Threaded
Open this post in threaded view
|

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

PICCA Frederic-Emmanuel
now we have the salsa pipeline.

does it fit your needs ?

Reply | Threaded
Open this post in threaded view
|

Using Jenkins Debian Glue to setup personal repos really quick (Was: [Idea] Debian User Repository?)

Ondřej Surý-4
In reply to this post by Kyle Edwards
It’s fairly easy nowadays with debian-jenkins-glue and jenkins-job-builder:


The launchpad PPAs are still slightly better (I cant rebuild individual matrix combinations from Jenkins), but only slightly. With qemu-user-static the even the armhf and arm64 builds works (mostly) fine.

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

On 8 Apr 2019, at 18:01, Kyle Edwards <[hidden email]> wrote:

On Mon, 2019-04-08 at 00:02 -0400, Peter Silva wrote:
If one needs to keep a close eye on changes to make sure they can still
be installed even on a years-old OS, the resulting packages can be
placed in a custom repository set up with the instructions at
<URL:https://wiki.debian.org/DebianRepository/Setup>. What am I missing?


yes, it can be done, but it is a lot more work for individual packagers.

launchpad.net combines:
   - very few clicks to build custom repositories.
   - a build environment for each OS, so that it runs "debuild" in the currently patched version of the OS for which the package it built.

It saves people from having to build their own custom repository, and from having to maintain a build environment for all supported OS versions and architectures.  on Ubuntu,  packages are built for 14.04, 16,04, 18.04, 18.10, 19.04, and I get all those just from clicking one box for each one. I think it also propagates re-building of packages when a build-dependency changes, without my knowledge or interaction.  It leverages the ubuntu build-farm for third-party packages.

With debian, it's kind of all or nothing.  Etiher you're in Debian, and it gets built on every platform using the build farm, or it's not, so you get no help at all. Launchpad gives a nice middle road that suits us right now, and if something similar were available for debian, it would provide a stepping stone to being in Debian proper.

CMake and VTK upstream here. This was my exact observation a while back when I tried to package VTK for Debian and Ubuntu. Packaging for Ubuntu was very easy: just upload your packaging script to launchpad.net and you're done. For Debian, I had to set up a build machine and an Aptly repository on a virtual machine that pulls in built packages from "incoming", inserts them into the Aptly repo, and rsyncs them to a web server, basically mimicking what the Debian repo infrastructure does. This was non-trivial to set up, and I found it frustrating that Launchpad-like infrastructure did not exist for Debian. (Building lots of packages is easy once you have the infrastructure, but the initial investment is rather high.) Just my $0.02.

Kyle
Reply | Threaded
Open this post in threaded view
|

Re: Using Jenkins Debian Glue to setup personal repos really quick (Was: [Idea] Debian User Repository?)

Holger Levsen-2
Hi Ondřej,

On Mon, Apr 08, 2019 at 06:14:57PM +0200, Ondřej Surý wrote:
> It’s fairly easy nowadays with debian-jenkins-glue and jenkins-job-builder:
>
> https://salsa.debian.org/ondrej/jenkins-job-builder.git
>
> The launchpad PPAs are still slightly better (I cant rebuild individual matrix combinations from Jenkins), but only slightly. With qemu-user-static the even the armhf and arm64 builds works (mostly) fine.

that sounds pretty interesting. What sources.lists does this produce?
Could you maybe add a short README file to your repo? :)


--
tschau,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

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

Re: Using Jenkins Debian Glue to setup personal repos really quick (Was: [Idea] Debian User Repository?)

Ondřej Surý-4
Hey,

check https://jenkins.rfc1925.org and f.e. https://packages.sury.org/php/

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

> On 8 Apr 2019, at 18:22, Holger Levsen <[hidden email]> wrote:
>
> Hi Ondřej,
>
>> On Mon, Apr 08, 2019 at 06:14:57PM +0200, Ondřej Surý wrote:
>> It’s fairly easy nowadays with debian-jenkins-glue and jenkins-job-builder:
>>
>> https://salsa.debian.org/ondrej/jenkins-job-builder.git
>>
>> The launchpad PPAs are still slightly better (I cant rebuild individual matrix combinations from Jenkins), but only slightly. With qemu-user-static the even the armhf and arm64 builds works (mostly) fine.
>
> that sounds pretty interesting. What sources.lists does this produce?
> Could you maybe add a short README file to your repo? :)
>
>
> --
> tschau,
>    Holger
>
> -------------------------------------------------------------------------------
>               holger@(debian|reproducible-builds|layer-acht).org
>       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Reply | Threaded
Open this post in threaded view
|

Re: Using Jenkins Debian Glue to setup personal repos really quick (Was: [Idea] Debian User Repository?)

Ondřej Surý-4
That repository is more of a remote backup, but I would be happy to collaborate on something more useful to general DD public...

There’s some additional content in this ticket that might go into the readme: https://github.com/oerdnj/deb.sury.org/issues/1092

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

On 8 Apr 2019, at 18:30, Ondřej Surý <[hidden email]> wrote:

Hey,

check https://jenkins.rfc1925.org and f.e. https://packages.sury.org/php/

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

On 8 Apr 2019, at 18:22, Holger Levsen <[hidden email]> wrote:

Hi Ondřej,

On Mon, Apr 08, 2019 at 06:14:57PM +0200, Ondřej Surý wrote:
It’s fairly easy nowadays with debian-jenkins-glue and jenkins-job-builder:

https://salsa.debian.org/ondrej/jenkins-job-builder.git

The launchpad PPAs are still slightly better (I cant rebuild individual matrix combinations from Jenkins), but only slightly. With qemu-user-static the even the armhf and arm64 builds works (mostly) fine.

that sounds pretty interesting. What sources.lists does this produce?
Could you maybe add a short README file to your repo? :)


--
tschau,
  Holger

-------------------------------------------------------------------------------
             holger@(debian|reproducible-builds|layer-acht).org
     PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
Reply | Threaded
Open this post in threaded view
|

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

Kyle Edwards
In reply to this post by PICCA Frederic-Emmanuel
On Mon, 2019-04-08 at 16:05 +0000, PICCA Frederic-Emmanuel wrote:
> now we have the salsa pipeline.
>
> does it fit your needs ?

Does this allow non-DD's to host packages? Nobody at Kitware is a DD,
we just host an unofficial third-party repository, similar to PPA.

Kyle

Reply | Threaded
Open this post in threaded view
|

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

Shengjing Zhu-3
In reply to this post by Mo Zhou
> from PPA (source+binary-based).

If people just want a PPA which supports Debian, please just take a
look at OBS[1].

I've seen many upstreams provide packages with OBS, and most
distributions are supported.
Not only deb, but also rpm, from Debian/Ubuntu to OpenSuse/Fedora, and
even Archlinux, in a uniform way.

[1] https://build.opensuse.org/


--
Shengjing Zhu

Reply | Threaded
Open this post in threaded view
|

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

PICCA Frederic-Emmanuel
In reply to this post by Kyle Edwards
After a build, you get this

https://salsa.debian.org/science-team/python-xrayutilities/-/jobs/147913/artifacts/browse/debian/output/

Is it enought for you.
Mayve you can discuss with the salsa pipeline team and request a target in order to produce a better repo.

cheers
Reply | Threaded
Open this post in threaded view
|

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

Ansgar Burchardt-8
In reply to this post by Paul Wise via nm
Paul Wise writes:
> On Mon, Apr 8, 2019 at 3:34 PM Mo Zhou wrote:
>
>> However, the translator itself is not trivial, as it might need
>> it's own shell parser or something alike to be reliable enough.
>
> Couldn't you just run makepkg (with some hooks) and dpkg-deb to
> convert the results to Debian packages?

How should this handle dependencies (probably named differently in
Debian) or maintainer scripts?

Tools like `alien` to convert RPM and Debian packages have similar
limitations and I don't remember them working that well.

Ansgar

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 Vincent Bernat-3
Vincent Bernat <[hidden email]> writes:

>  ❦  8 avril 2019 14:46 +10, Ben Finney <[hidden email]>:
>
> >> yes, it can be done, but it is a lot more work for individual
> >> packagers.
> >
> > Sure. And, on the other hand, providing an APT repository for arbitrary
> > packages of unknown copyright status is also a lot of work to expect
> > disinterested volunteers to do without motivation.
>
> Disinterested volunteers are never forced to work for Debian.

Yes, that's why I said “expect” and not “force”.

> What is the point of being so negative?

Not sure who you're addressing here, and I'm sorry if the discussion
appears negative to you.

--
 \          “When I get real bored, I like to drive downtown and get a |
  `\         great parking spot, then sit in my car and count how many |
_o__)                    people ask me if I'm leaving.” —Steven Wright |
Ben Finney

Reply | Threaded
Open this post in threaded view
|

Re: duprkit User Repository

Mo Zhou
In reply to this post by Roberto C. Sánchez-2
Hi,

On Mon, Apr 08, 2019 at 10:22:42AM -0400, Roberto C. Sánchez wrote:
>
> Two suggestions:
>
> - Stop claiming that what you propose is "zero-cost", "only 1 second of
>   work", etc.*

And, I'm already tired of saying that again and again.

> - Find the individuals who currently experience the greatest pain
>   associated with the problem you are trying to solve and whose pain is
>   relieved by your solution.  Get them to adopt it.  If it works as well

/me. The packaging work for at least cudnn, bazel, pytorch, tensorflow
and their dependencies will stall if one targets on high quality and
policy-compliant work, because I believe they don't worth investing huge
amount of time to be made policy-compliant.

>   as you say it does, they will be enthusiastic adopters and will have
>   no problem telling others, in concrete terms, how much better your
>   solution is than whatever the current situation is.

This idea, or the prototype, needs to be lucky enough to be properly
spreaded among the targeted users. However, if nobody believed in
the insight or the motivation, the idea has failed at the beginning.
 

> * Even in a perfect world, nothing is "zero-cost."  To a community of
>   contributors whose purpose it is to build an operating system
>   distribution a deep understanding of the components that compose the
>   system and the components used to build the system are effectively a
>   requirement.  Thus, if I came along and said, "here, I have a drop-in
>   replacement for utility 'foo', and I call the replacement 'bar', and
>   it supports all the same options as 'foo' so that you can use it
>   without having to think about any differences" I would still expect
>   that there would be a need for me to convince potential adopters that
>   things really work that way.  Experience tells us that even "drop in"
>   replacements for things are seldom that "perfect" when it comes to
>   compatibility with whatever they are replacing.

Fair enough. Since both traditional debian/ layout and the single-file
cruft are supported explicitly, I'll stop replying comments on preference.

Reply | Threaded
Open this post in threaded view
|

[prototype] Debian User Repository Toolkit 0.0a release

Mo Zhou
In reply to this post by Mo Zhou
Hi list,

I drafted a 0.0 alpha release[1] for the toolkit, and created a logo for
the DUPR project. From now on I'll try to add more packaging scripts
(maybe I should call them recipes) to the default collection[2].
Packaing plans are tracked here[3], and maybe further discussion about
the DUPR (DUR, whatever.) should be redirected to a dedicated issue[4].
And, I hope someone could put forward a better name for these prototypes
(naming issue tracked here: [6]).

The prototype implementation[5] needs time to grow, evolve, and listen
to the others. Time will see everything. Please help me spread the
underlying idea and the reference implementation[5] if you agree with my
original motivation.

Thanks for your patient, and support,
Mo

[1] https://github.com/dupr/duprkit/releases/tag/0.0a
[2] https://github.com/dupr/DefaultCollection
[3] https://github.com/dupr/DefaultCollection/issues
[4] https://github.com/dupr/duprkit/issues/9
[5] https://github.com/dupr
[6] https://github.com/dupr/duprkit/issues/2

Reply | Threaded
Open this post in threaded view
|

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

Vincent Bernat-3
In reply to this post by Ben Finney-3
 ❦  9 avril 2019 08:41 +10, Ben Finney <[hidden email]>:

>> >> yes, it can be done, but it is a lot more work for individual
>> >> packagers.
>> >
>> > Sure. And, on the other hand, providing an APT repository for arbitrary
>> > packages of unknown copyright status is also a lot of work to expect
>> > disinterested volunteers to do without motivation.
>>
>> Disinterested volunteers are never forced to work for Debian.
>
> Yes, that's why I said “expect” and not “force”.
Being forced is the definition of expect.

"to consider bound in duty or obligated they expect you to pay your
bills" <https://www.merriam-webster.com/dictionary/expect>

>> What is the point of being so negative?
>
> Not sure who you're addressing here, and I'm sorry if the discussion
> appears negative to you.

I am addressing you. You try to dissuade people on the basis this is
work you are not interested to do. If someone was implementing PPA/DPA,
what would be the downside for people not interested in them? None. You
can just ignore the feature.
--
Must I hold a candle to my shames?
                -- William Shakespeare, "The Merchant of Venice"

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

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

Marvin Renich
* Vincent Bernat <[hidden email]> [190409 01:26]:

>  ❦  9 avril 2019 08:41 +10, Ben Finney <[hidden email]>:
>
> >> >> yes, it can be done, but it is a lot more work for individual
> >> >> packagers.
> >> >
> >> > Sure. And, on the other hand, providing an APT repository for arbitrary
> >> > packages of unknown copyright status is also a lot of work to expect
> >> > disinterested volunteers to do without motivation.
> >>
> >> Disinterested volunteers are never forced to work for Debian.
> >
> > Yes, that's why I said “expect” and not “force”.
>
> Being forced is the definition of expect.
>
> "to consider bound in duty or obligated they expect you to pay your
> bills" <https://www.merriam-webster.com/dictionary/expect>

No, "expect" means that one person has a belief that another person has
some obligation (note the word "consider" in the definition you quoted).
An expectation does not need to, and very often does not, have any
coercion ("force") associated with it.  Expectations are often not met,
and are sometimes not even reasonable.

> >> What is the point of being so negative?
> >
> > Not sure who you're addressing here, and I'm sorry if the discussion
> > appears negative to you.
>
> I am addressing you. You try to dissuade people on the basis this is
> work you are not interested to do. If someone was implementing PPA/DPA,
> what would be the downside for people not interested in them? None. You
> can just ignore the feature.

I don't believe he was being negative.  Combining the paragraph you
quoted with his next paragraph, I interpreted it as "Your idea may not
align with the principles of the Debian project as a whole, but you seem
to have enough capable developers who are interested in your idea to
implement it outside of Debian."

That sounded constructive and encouraging, while redirecting away from a
solution that he did not believe would (or should?) work for reasons
related to the ideals of the project.

...Marvin

123456