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

[Eli Schwartz]

On 1/6/19 2:00 PM, JereBear wrote:
>>> 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.
>>
>> Documentation is always good! You're not the first one to ask about
>> where local:// is documented, I think, but documentation issues are
>> difficult to remember without a bug report when the people most likely
>> to be writing documentation think it is obvious because they've read the
>> implementation. :p
> 
> https://bugs.archlinux.org/task/61294

I noticed another bug when looking at your referenced package.

You used local:/// rather than local://, but aurweb displays this as
relative to the cgit repository. Since we use php's parse_url() to check
if it validates as having an

Array
(
    [scheme] => something
)

- but, parse_url() will special-case file:// in order to treat it
  correctly, and otherwise
- parse local://filename as a schema+host, and
- parse local:///filename as malformed ("On seriously malformed URLs,
  parse_url() may return FALSE.")

So this completely borks if scheme:/// is used and treats it as local to
the cgit repository as the fallback for plain files, since it cannot get
an $array['scheme'] from a boolean FALSE. It doesn't look like
parse_url() is very suitable here... makepkg does not care either way,
since it looks for the final pathname component by discarding everything
before the last "/".

This is an aurweb bug, as I think we should abort on malformed urls and
display them as-is, like we already do for urls that are on the RHS of
makepkg's "::" syntax. Or possibly use the same dumb parser we use in
the db backend for consistency's sake...

...

Also I think all previous cases of people using local:// in a PKGBUILD
did not use "/filename", so we were happily parsing it as an authority.
You've actually broken the aurweb in a practical way by actually caring
about the RFC. :D

-- 
Eli Schwartz
Bug Wrangler and Trusted User

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