[aur-general] package review request: gog-pyre

[JereBear]

> If you like, you can report a bug to the aurweb parser arguing that
> you'd like to use your RFC 3986 right to an empty URI authority in
> combination with a permissive file: scheme. But currently, attempting to
> push that to the AUR will result in failure due to rejecting any source
> that does not contain the string literal :// and is also not committed
> to the git repository.
>
> Furthermore, makepkg itself does the same thing, and considers
> file:/path to be a relative filesystem path for "./file:/path", which,
> since makepg does not support subdirectories (whether that subdirectory
> name has a ":" in it in a manner reminiscent of RFC 3986 is not
> relevant) the leading directory will simply be dropped at every point
> where makepkg attempts to parse it.
>
> ...
>
> personally I don't see much use for skipping the ://, file:/// works
> everywhere and is more easily parsed.
>
> ...
>
> Since the only reason to use any scheme at all is to pass validation for
> aurweb, you won't notice anything wrong with makepkg.
>
> As for local://, it is special-cased in makepkg -- if makepkg sees it,
> it will not try to handle it as a download url no matter what. You can
> get a similar result by using sdfsgsgfdiuyicl:// since makepkg does most
> likely not have a DLAGENTS=() handler for this and will therefore tell
> you it cannot figure out how to download it... but it's the difference
> between "unknown download client" and "was not found in the build
> directory and is not a URL."

Interesting. In the strictest case, the first phase of parsing the file scheme
could consist of matching ^file:(\/\/([a-z0-9-]+)?)? and providing default
values for missing capture groups. But this only makes sense if the file
scheme is, well, to be supported. I'll think on this.

Thanks for the info about the local pseudo-scheme. I've made a note to
file a feature request on bugs.archlinux.org, asking for documentation.
(Obligatory "and maybe a patch, but don't count on it.") And I'll switch to
using it.

> > Shall I leave both of the variable assignments commented out, so that
> > makepkg.conf is respected, and so that the user is aware of possible
> > solutions? Or do you think it's better practice to omit such comments
> > altogether?
>
> I'm of the opinion people should read the documentation and set
> PKGEXT=.pkg.tar as described here:
> https://wiki.archlinux.org/index.php/Makepkg#Use_other_compression_algorithms
>
> Or the next tip which shows how to modify COMPRESSXZ

I'll insert a comment linking to the wiki. Anticipates user needs while
remaining DRY.

> makechrootpkg is designed to run makepkg in a highly controlled
> environment suitable for official packaging. It's undesirable for
> makepkg settings like PKGEXT to leak from a developer's machine into the
> environment used for uploading packages to the official repos.
>
> If you need something else, then don't use extra-x86_64-build, and
> instead mkarchroot with the makepkg.conf you want to initialize into the
> chroot. Or use arch-nspawn -M <file> to copy your makepkg.conf over the
> next time you do chroot administration.

Ah-ha! It's good to know the target use case for extra-x86_64-build and
makechrootpkg. And I hadn't thought about using separate chroots for public vs
private builds, or inserting files with arch-nspawn -M $file. Good stuff.

> That's quite sad, but if there's no way in makeself to extract the
> assets zip without using mojosetup, then I guess you're doing the best
> you can.

I legitimately think stripping bytes is the best option.

> > symlinking to start.sh is not an option here. :-( Here's the contents of gog-pyre:
> >
> >     #!/usr/bin/env bash
> >
> >     # Setting TERM prevents the application from crashing with "System.Exception:
> >     # Magic number is wrong: 542." See: https://github.com/mono/mono/issues/11557
> >     TERM=xterm /opt/gog-pyre/start.sh
> >
> > I suspect that this workaround is only necessary because Pyre bundles dependencies.
>
> Oh well, it was worth a thought -- but next time you can post the script
> as well as the PKGBUILD and we'll know what it's doing right off the bat. ;)

Yeah, I didn't think this through.