Web lists-archives.com

Re: duprkit User Repository

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

Ondřej Surý <ondrej@xxxxxxxx>

> On 8 Apr 2019, at 11:58, Mo Zhou <lumin@xxxxxxxxxx> 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.