Re: duprkit User Repository
- Date: Mon, 8 Apr 2019 08:36:45 -0400
- From: Roberto C. Sánchez <roberto@xxxxxxxxxx>
- Subject: Re: duprkit User Repository
On Mon, Apr 08, 2019 at 11:02:35AM +0000, Mo Zhou wrote:
> On Mon, Apr 08, 2019 at 12:37:36PM +0200, Ondřej Surý wrote:
> > I very much dislike the idea of inventing yet another format. Your
> > energy would be much better used if you rather added support for
> > external tarballs to the packaging tools (with hashes, etc.) and turn
> > this into DEP.
> There is merely a tiny overhead in the plain text formats. Well, people
> have different preferences and I still need time to see whether such
> proposed formats are fine.
> I found some existing problem, as what I said in the very first
> paragraph of the original post. And I think I've already made the
> motivation clear there. If the motivation turns to be useful enough,
> why should we reject thinking about something new?
> > Debian is not Fedora/Arch/... and whacking the debian/ into a single
> > file doesn’t feel like something that would help anything at all. Just
> > require git (as AUR4 does).
> Debian is different from the other distros. Particularly, Debian is a
> binary-based distribution. By creating such a user packaging repo, some
> advantages of source-based distributions could be introduced.
> And most importantly, anyone who dislike the single-file format
> could just commit the debian directory to the repo, and remove
> the do_unfold() hook from the header script. That's not recommended
> but it still work without the single-file format. Anyway the
> single-file format is only a part of the idea, and we can remove
> it if most people don't like it.
Let me make a suggestion based on something that I learned quite some
years ago as a young engineer fresh from school: the best technical
solution is only the best overall solution if it also addresses all (or
most) of the relevant non-technical factors.
Rather than focus on the "tiny" technical overhead, focus on the
quality and value of the improvements that justify to a community of
thousands of contributors why they should willingly accept the
additional cognitive burden of the change you are proposing.
If you think about the proposals that have succeeded in becoming de
facto or de jure (in the form of debian-policy) standards within Debian,
every one of them has required lots of people see why *additional work*
for them was beneficial to them *and everyone else* as well. They also
had to agree that they themselves and the project as a whole saw
sufficient benefit to warrant the change/additional work.
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.
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.)
Roberto C. Sánchez