[aur-general] New package: disklow

[Eli Schwartz]

On 9/2/19 7:31 AM, Holger Jahn wrote:
> Hi Daniel,
> 
> Thanks for your review.
> 
>> You'll need to install the PerlArtistic license.
> 
> What exactly do you mean by "install the license"? Put a copy of it into
> the package?

core/licenses provides /usr/share/licenses/common/PerlArtistic/license.txt

If you were actually in need of installing the license, then you would
do so in accordance with
https://wiki.archlinux.org/index.php/PKGBUILD#license


>> This may be a small tool, but you're not really supposed to host the
>> source code in the AUR. It should be hosted elsewhere and downloaded.
> 
> The payload code is one Perl script with 1400+ lines.
> 
> For brevity's sake I am trying to keep it in one package, but if the
> community rules dictate to split it into PKGBUILD & source, then so be it.

The AUR graciously provides hosting for build recipes (PKGBUILD) and
additional files needed for packaging (desktop files, those tiny
shellscript wrappers which the java ecosystem is accursed with, kernel
.config files, systemd units if upstream doesn't provide them, etc).

The AUR does not provide source code hosting, on the grounds that other
places like Github, Gitlab, git.sr.ht, amd so on are doing it better.
Moreover, source code hosting is a resource burden on the provider,
which in our case we do not have either a business or community
rationale for accepting. (Again: we provide hosting for build recipes,
because build recipes are something specific to Arch).

We actually have a rudimentary enforcement method in the form of an
upload validation script that will reject packages containing files
which are "too big" and therefore seem like they cross the line from
packaging files to source code.

...

More generally, why would you upload your project in a way that is
targeted exclusively for Arch users? What if users of a different distro
wanted to use your software?

And, regardless of where you host it, why would you upload it as a
tarball checked into git? git already has excellent deduplication
algorithms and the ability to diff versions of a file, but it is geared
to text and is kind of terrible at handling often-changing binary files
like a gzipped tarball. Over time, a repo containing tarballs will
balloon in size.

>> MD5 is old (and, some would argue, busted). Prefer SHA1, or better,
>> SHA256.
> 
> I wrote a little build script in order to wrap everything into the
> package itself. The script uses
> 
> makepkg -g >> PKGBUILD
> 
> which produces the md5sums array. How do I get it to use something else
> than md5sum? Simply roll my own by using sha256sum?

makepkg -g will generate new checksums for a PKGBUILD, using all the
current checksum algorithms listed in the PKGBUILD, or, if there are
none, using the INTEGRITY_CHECK setting in makepkg.conf

The INTEGRITY_CHECK defaults to md5.

...

Aside: using makepkg -g >> PKGBUILD will lead to repeatedly appending
checksum lines, which you will need to edit in order to remove old
versions. The updpkgsums script from pacman-contrib will use makepkg -g
in order to update checksums in-place.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20190902/8d0ace22/attachment.sig>