[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: duprkit User Repository

Andrey Rahmatullin-3
On Mon, Apr 08, 2019 at 09:58:26AM +0000, Mo Zhou wrote:
> AUR's PKGBUILD, Fedora/CentOS/RedHat's .spec, Gentoo's .ebuild,
> all of them are single-file format. The advantages of single-file
> format includes easy distribution, e.g. copying & pasting from
> webpages (you cannot copy a directory from a webpage).
This only works when you don't need patches.

--
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
I don’t think you need to avoid using “Debian” in the name.

This is the least problem your proposal have.

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

> On 8 Apr 2019, at 12:27, Mo Zhou <[hidden email]> wrote:
>
> Hi,
>
> D**ian may be pronounced as "Dasteriskian", i.e. "D-asterisk-ian"
> (Still sounds ugly). I'm really bad at naming things, neither.
>
> AUR is not targeted on new Archlinux users. Likewise, the D**bian
> term is not expected to cause confusion to people who really
> need to use these scripts/tools. That said, I want a better name
> too.
>
>> On Mon, Apr 08, 2019 at 12:05:56PM +0200, W. Martin Borgert wrote:
>> Quoting Mo Zhou <[hidden email]>:
>>> As you wish, I added a disclaimer to the toolkit, and replaced every
>>> single "Debian" keyword in the repo with "D**ian", except for those
>>> in disclaimer.
>>
>> Pardon, but replacing letters with '*' looks like Debian were a
>> swearword ("f*ck", "sh*t", ...) one likes to avoid. Also, it is
>> not a good name, because nobody knows how to pronounce it nor
>> which letters exactly were replaced. I'm bad at naming, sorry,
>> but please find something else before people get used to it :-)
>

Reply | Threaded
Open this post in threaded view
|

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

Holger Levsen-2
In reply to this post by Jonathan Dowland
On Mon, Apr 08, 2019 at 10:18:39AM +0100, Jonathan Dowland wrote:

> > 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).
> This supports my (thus far) private feeling that naming this initiative
> "Bikeshed" is a bad idea.
+1

I also think that using the name "D**ian" is a bad idea.

Just call it PPAs... millions of people know that term.


--
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: duprkit User Repository

Ondřej Surý-4
In reply to this post by Mo Zhou
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.

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

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

> On 8 Apr 2019, at 11:58, Mo Zhou <[hidden email]> wrote:
>
> Hi,
>
>> On Mon, Apr 08, 2019 at 08:54:27AM +0100, Phil Morrell wrote:
>> On Mon, Apr 08, 2019 at 05:00:21AM +0000, Mo Zhou wrote:
>>
>> Obviously working implementation > perfect theoretical, but I'm confused
>> by your insistence on a single file without abstraction. Even an
>> uncompressed tarball can be cat'ed to read the contents, without
>
> AUR's PKGBUILD, Fedora/CentOS/RedHat's .spec, Gentoo's .ebuild,
> all of them are single-file format. The advantages of single-file
> format includes easy distribution, e.g. copying & pasting from
> webpages (you cannot copy a directory from a webpage).
>
> The single-file format doesn't accept binary blobs since they
> are not review-able.
>
>> requiring a custom format. With a custom format, why not hide
>> implementation details like source format in "unfold"?
>
> Explicitness. Source code is short, and users can quickly understand
> what's happending when nothing is hidden. Besides, there is nearly
> no overhead in the "unfold" plain text format, right?
>
>> For the DefaultCollection example, don't we have a standardised download
>> tool in debian/watch?
>
> Whether to use debian/watch and uscan depends on the .durpkg author.
> The nature of AUR's PKGBUILD is that, whoever use the package
> is the one who update it. Maybe this is what should be improved
> in the future but it doesn't block anything.
>
>> Similarly, the build script is essentially a debian/rules in its construction.
>> Could you get by with a `cat debian/{watch,control,rules}`?
>
> The header script is not really what debian/rules does. For example,
> when you are going to build some official Debian package, you may want
> to do the following:
>
>  $ debcheckout foobar
>  $ cd foobar; gbp export-orig; debuild -S -nc
>  $ sbuild -j4 foobar.dsc
>  $ rm -rf foobar
>
> And the header script defines things like the above commands. I changed
> the shell function name "do_build" -> "do_trigger_build", because the
> header script only defines "how to trigger the build", and the
> definition of "how to build" is still in debian/rules.
>

Reply | Threaded
Open this post in threaded view
|

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

Ondřej Surý-4
In reply to this post by Holger Levsen-2
Or DPA (Debian Personal Archive)...

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

> On 8 Apr 2019, at 12:32, Holger Levsen <[hidden email]> wrote:
>
> On Mon, Apr 08, 2019 at 10:18:39AM +0100, Jonathan Dowland wrote:
>>> 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).
>> This supports my (thus far) private feeling that naming this initiative
>> "Bikeshed" is a bad idea.
>
> +1
>
> I also think that using the name "D**ian" is a bad idea.
>
> Just call it PPAs... millions of people know that term.
>
>
> --
> 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: duprkit User Repository

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

On Mon, Apr 08, 2019 at 03:31:21PM +0500, Andrey Rahmatullin wrote:
> On Mon, Apr 08, 2019 at 09:58:26AM +0000, Mo Zhou wrote:
> > AUR's PKGBUILD, Fedora/CentOS/RedHat's .spec, Gentoo's .ebuild,
> > all of them are single-file format. The advantages of single-file
> > format includes easy distribution, e.g. copying & pasting from
> > webpages (you cannot copy a directory from a webpage).
>
> This only works when you don't need patches.

The design of "duprkit" didn't forget patches at all.

There are many ways to apply apply patches:

1. Put separated patches to the Collection repository, as per the
   collection specification: https://github.com/dupr/DefaultCollection
   Then apply it manually in the header script of .durpkg .
   This is similar to what AUR does.

2. If one like, just fold the patches into the .durpkg, which may result
   in some extra lines in the .durpkg:

   ^ debian/patches/series
   foobar.patch
   ^ debian/patches/foobar.patch
   -foo bar
   +foobar

   And you may beed to change the source/format accordingly.

   The fact is, any plain file, as long as none of its lines starts with
   a single '^', could be folded into the .durpkg or the .f822 file.
   Detailed file format specification can be found in the code comments[1]

3. Fold the patches into .durpkg, but not in the quilt format.

   ^ some-working-directory/xxx.patch
   -foo bar
   +foobar

   The header script of .durpkg is able to use it.

4. may be more? ...

[1] https://github.com/dupr/duprkit/blob/master/bin/unfold

Reply | Threaded
Open this post in threaded view
|

Re: duprkit User Repository

Jonathan Carter (highvoltage)-2
In reply to this post by Ondřej Surý-4
On 2019/04/08 12:37, 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.
>
> 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).

Indeed. I can see why Mo would want to put it in one file, but the
Debian package format can work just fine if you work from git
repositories as you suggest, plus if it looks like a more or less usual
debian source package, then it's a smaller leap to turn it into a real
package that can graduate into making its way into Debian.

-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: duprkit User Repository

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

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.

Reply | Threaded
Open this post in threaded view
|

Re: duprkit User Repository

Mo Zhou
In reply to this post by Jonathan Carter (highvoltage)-2
On Mon, Apr 08, 2019 at 12:51:15PM +0200, Jonathan Carter wrote:
> On 2019/04/08 12:37, Ondřej Surý wrote:
>
> Indeed. I can see why Mo would want to put it in one file, but the
> Debian package format can work just fine if you work from git
> repositories as you suggest, plus if it looks like a more or less usual
> debian source package, then it's a smaller leap to turn it into a real
> package that can graduate into making its way into Debian.

There is really shockingly small overhead for the single-file format.
At the mean time, converting things between the debian-folder and
single-file formats is really quick, smooth and easy with fold[1] and
unfold[2]. The only problem there is the conversion will fail if binary
blobs exist (not supported yet).

[1] https://github.com/dupr/duprkit/blob/master/bin/fold
    #!/bin/sh
    for file in $(find $1 -type f | sort); do
    echo "^ $file"
    cat $file
    done
[2] https://github.com/dupr/duprkit/blob/master/bin/unfold

Reply | Threaded
Open this post in threaded view
|

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

Mo Zhou
In reply to this post by Holger Levsen-2
Hi,

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.

The proposed idea is to take some advantages from source-based
software distribution tools. Examples are available here:
https://github.com/dupr/duprkit
https://github.com/dupr/DefaultCollection

Only "packaging scripts" are provided. Upstream source are
downloaded by the scritps locally before the build. The proposed
idea will never involve "distributing resulting binary .deb packages".

Again, the idea is totally different from PPA.

On Mon, Apr 08, 2019 at 10:32:46AM +0000, Holger Levsen wrote:

> On Mon, Apr 08, 2019 at 10:18:39AM +0100, Jonathan Dowland wrote:
> > > 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).
> > This supports my (thus far) private feeling that naming this initiative
> > "Bikeshed" is a bad idea.
>
> +1
>
> I also think that using the name "D**ian" is a bad idea.
>
> Just call it PPAs... millions of people know that term.

Reply | Threaded
Open this post in threaded view
|

Re: duprkit User Repository

Johannes Schauer-3
In reply to this post by Mo Zhou
Hi,

Quoting Mo Zhou (2019-04-08 11:58:26)
> The header script is not really what debian/rules does. For example,
> when you are going to build some official Debian package, you may want
> to do the following:
>
>   $ debcheckout foobar
>   $ cd foobar; gbp export-orig; debuild -S -nc
>   $ sbuild -j4 foobar.dsc
>   $ rm -rf foobar

OT to this thread but just as general info: If you are already using sbuild
then all of this can be reduced to:

    $ sbuild -d unstable foobar

The -d option chooses your configured schroot distribution, but you can as well
pass any other (s)chroot with the -c option instead.

You can also build source packages from other archives (like a PPA) even if the
respective source URLs do not exist in your build chroot. For example here I'm
building the non-free package "arb" from the non-free repository:

    $ sbuild -d unstable --extra-repository="deb-src http://ftp.de.debian.org/debian/ unstable non-free" arb

So if you end up just having a deb-src archive somewhere, then building
packages from it in a chroot is just a single command.

Thanks!

cheers, josch

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

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

W. Martin Borgert
In reply to this post by Mo Zhou
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.

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 Mon, Apr 08, 2019 at 06:49:10AM +0000, Mo Zhou wrote:
> Hi,
>
> As you wish, I added a disclaimer to the toolkit, and replaced every
> single "Debian" keyword in the repo with "D**ian", except for those
> in disclaimer.

Perhaps using ".deb" instead of "Debian" or "D**ian" might be more
practical.  After all, the whole exercise seems to be more focused on
the packaging and distribution of said packages, rather than "Debian the
GNU/Linux distribution" as a project.  If there are places where the
leading dot might be impractical or confusing, then perhaps "dotdeb" or
"dot-deb" might be more workable.

Regards,

-Roberto
--
Roberto C. Sánchez

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 10:47:20AM +0000, Mo Zhou wrote:

> Hi,
>
> On Mon, Apr 08, 2019 at 03:31:21PM +0500, Andrey Rahmatullin wrote:
> > On Mon, Apr 08, 2019 at 09:58:26AM +0000, Mo Zhou wrote:
> > > AUR's PKGBUILD, Fedora/CentOS/RedHat's .spec, Gentoo's .ebuild,
> > > all of them are single-file format. The advantages of single-file
> > > format includes easy distribution, e.g. copying & pasting from
> > > webpages (you cannot copy a directory from a webpage).
> >
> > This only works when you don't need patches.
>
> The design of "duprkit" didn't forget patches at all.
>
> There are many ways to apply apply patches:
>
> 1. Put separated patches to the Collection repository, as per the
>    collection specification: https://github.com/dupr/DefaultCollection
>    Then apply it manually in the header script of .durpkg .
>    This is similar to what AUR does.
>
If I interpret this correctly, your idea becomes, "use a single file
package specification, except for the parts that live somewhere
completely external and separate from the package."  That seems like you
have *increased* the complexity of the packaging format, rathern than
decreased it.

> 2. If one like, just fold the patches into the .durpkg, which may result
>    in some extra lines in the .durpkg:
>
>    ^ debian/patches/series
>    foobar.patch
>    ^ debian/patches/foobar.patch
>    -foo bar
>    +foobar
>
>    And you may beed to change the source/format accordingly.
>
>    The fact is, any plain file, as long as none of its lines starts with
>    a single '^', could be folded into the .durpkg or the .f822 file.
>    Detailed file format specification can be found in the code comments[1]
>
> 3. Fold the patches into .durpkg, but not in the quilt format.
>
>    ^ some-working-directory/xxx.patch
>    -foo bar
>    +foobar
>
>    The header script of .durpkg is able to use it.
>
> 4. may be more? ...
>
Even these other points seem like they require some effort to "prep" the
packaging so that it exists in a single file and would require similar
effort to separate the components out.

All of this for "copy & pasting from webpages" seems like the epitome of
"style over substance".  Why on earth is copying and pasting from
webpages *so* important that the entire packaging format has to be
reworked?

If somebody is challenged by the obstacle of 'apt-get source ...' or
'debcheckout ...' then perhaps making the packaging into a single file
so that it can be copy/pasted from a webpage might not be solving the
correct problem.

Regards,

-Roberto

--
Roberto C. Sánchez

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 Roberto C. Sánchez-2
Hi,

On Mon, Apr 08, 2019 at 08:18:53AM -0400, Roberto C. Sánchez wrote:

> On Mon, Apr 08, 2019 at 06:49:10AM +0000, Mo Zhou wrote:
> > Hi,
> >
> > As you wish, I added a disclaimer to the toolkit, and replaced every
> > single "Debian" keyword in the repo with "D**ian", except for those
> > in disclaimer.
>
> Perhaps using ".deb" instead of "Debian" or "D**ian" might be more
> practical.  After all, the whole exercise seems to be more focused on
> the packaging and distribution of said packages, rather than "Debian the
> GNU/Linux distribution" as a project.  If there are places where the
> leading dot might be impractical or confusing, then perhaps "dotdeb" or
> "dot-deb" might be more workable.

However the idea involves no distribution of any single ".deb" file.
That's more likely a "User Recipe Repository", instead of a "User dishes
Repository". People will ask "where on earth are your .deb files?" if
I put ".deb" to the title.

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 11:02:35AM +0000, Mo Zhou wrote:

> Hi,
>
> 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.)

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 Mo Zhou
On Mon, Apr 08, 2019 at 12:29:56PM +0000, Mo Zhou wrote:

> Hi,
>
> On Mon, Apr 08, 2019 at 08:18:53AM -0400, Roberto C. Sánchez wrote:
> > On Mon, Apr 08, 2019 at 06:49:10AM +0000, Mo Zhou wrote:
> > > Hi,
> > >
> > > As you wish, I added a disclaimer to the toolkit, and replaced every
> > > single "Debian" keyword in the repo with "D**ian", except for those
> > > in disclaimer.
> >
> > Perhaps using ".deb" instead of "Debian" or "D**ian" might be more
> > practical.  After all, the whole exercise seems to be more focused on
> > the packaging and distribution of said packages, rather than "Debian the
> > GNU/Linux distribution" as a project.  If there are places where the
> > leading dot might be impractical or confusing, then perhaps "dotdeb" or
> > "dot-deb" might be more workable.
>
> However the idea involves no distribution of any single ".deb" file.
> That's more likely a "User Recipe Repository", instead of a "User dishes
> Repository". People will ask "where on earth are your .deb files?" if
> I put ".deb" to the title.
>
OK.  Thanks for the explanation.  It seems like I did not properly grasp
that aspect of it.

Regards,

-Roberto

--
Roberto C. Sánchez

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,

The use of single-file format is not mandatory to the whole idea.
With no effort I transformed the single-file format into the traditional
format which you like:
https://github.com/dupr/DefaultCollection/tree/master/rover-traditional

Please choose use whatever you like.

On Mon, Apr 08, 2019 at 08:26:53AM -0400, Roberto C. Sánchez wrote:
> On Mon, Apr 08, 2019 at 10:47:20AM +0000, Mo Zhou wrote:
> If I interpret this correctly, your idea becomes, "use a single file
> package specification, except for the parts that live somewhere
> completely external and separate from the package."  That seems like you
> have *increased* the complexity of the packaging format, rathern than
> decreased it.

It doesn't take more than 1 second to convert between a traditional
debian/ directory of the proposed single file format:
https://github.com/dupr/duprkit/blob/master/bin/fold
https://github.com/dupr/duprkit/blob/master/bin/unfold
And I don't prevent anybody from submitting a debian directory:
https://github.com/dupr/DefaultCollection/commit/6ba5e0a310dc287dbd8ff1b276e1c3da0d896ebd
I encourage people do whatever they like to get the thing done.

Strictly speaking the single-file format has indeed introduced a little
overhead but it's not mandatory.

> Even these other points seem like they require some effort to "prep" the
> packaging so that it exists in a single file and would require similar
> effort to separate the components out.
 
If such 1-second workload is unacceptable, just go in the traditional
way please.
https://github.com/dupr/DefaultCollection/commit/6ba5e0a310dc287dbd8ff1b276e1c3da0d896ebd

> All of this for "copy & pasting from webpages" seems like the epitome of
> "style over substance".  Why on earth is copying and pasting from
> webpages *so* important that the entire packaging format has to be
> reworked?

I don't ask anybody to use it if you don't like the single-file format.
If such 1-second workload is unacceptable, just go in the traditional
way please.

> If somebody is challenged by the obstacle of 'apt-get source ...' or
> 'debcheckout ...' then perhaps making the packaging into a single file
> so that it can be copy/pasted from a webpage might not be solving the
> correct problem.

AUR users are expected to be able to take care of themselves.
If the users cannot even solve the error from "apt-get source"
or "debcheckout", why should they even try a "recipe-only" (or
packaging-script-only, source-only, whatever) way to build or
install something?

Reply | Threaded
Open this post in threaded view
|

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

Tzafrir Cohen
In reply to this post by Mo Zhou
Hi,


On 08/04/2019 14:18, Mo Zhou wrote:

> Hi,
>
> 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.
>
> The proposed idea is to take some advantages from source-based
> software distribution tools. Examples are available here:
> https://github.com/dupr/duprkit
> https://github.com/dupr/DefaultCollection

The README states a directory structure with a top-level collection
directory, but the repository currently does not include one.


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 changelog is buried deep inside the package an needs to be updated
whenever a version number is bumped.


-- Tzafrir

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

123456