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