[aur-general] Deletion of discord-updater{,-canary}?

[Morgan Adamiec]

On 10 May 2018 at 01:50, Eli Schwartz via aur-general
<aur-general at archlinux.org> wrote:
> On 05/09/2018 08:29 PM, Morgan Adamiec via aur-general wrote:
>> discord-updater is quite a confusing package to me. I'm not sure is I
>> should file a deletion request for it.
>>
>> When discord needs an update it will refuse to start until it is
>> updated. This package appears to be designed to download the latest
>> discord .tar.gz and extract it to ~/.local. By passing the need to
>> wait for updates on the main discord AUR package.
>>
>> My question here is does this count as a duplicate to discord? And
>> even if it does not should this really be in the AUR in the first
>> place? It is just a simple script really.
>
> I'm not sure I see a reason for this package either, especially
> considering this will tend to duplicate lots of content in a multi-user
> setup.
>
>> For future reference I would appreciate if anyone can tell me the
>> correct place to send this sort of thing. Here, to aur-requests or
>> type it into the request box on the AUR page.
>
> Submitting a deletion request is something you should do when you're
> pretty sure that's the action that should be taken. If you're unsure,
> then aur-general is a reasonable enough place to inquire about policy.
>
>> Also on a similar topic, the package discord-always-canary was removed
>> from the AUR by Eschwartz. This package is essentially discord-canary
>> with a pkgver() function. Meanwhile firefox-always-nightly is still on
>> the AUR and is essentially the same idea.
>
> I noticed the former, while dealing with a package request. I never
> noticed the latter. :D
>
> But I don't see the point of that either, especially considering
> firefox-nightly is pretty good about tracking this properly.
>
>> Is there a reason the discord-always-canary can not exist, similar to
>> pkg and pkg-git? I get they comparison is not exactly the same because
>> both discord packages source stable versions.
>
> git packages specifically refer to the latest VCS sources. They're 1)
> development versions, 2) building different code, 3) tracking something
> which is inherently changeable.
>
> packages which are nominally stable releases, but get updated nightly,
> are an interesting issue. I don't think anyone is served by having two
> packages for it though -- I figure this is reasonable:
>
>> Instead would it be a good idea to add a pkgver() function to the main
>> discord packages? As mentioned discord will refuse to start when out
>> of date, so most users are stuck waiting for the maintainer to update
>> it.
>
> This would probably make sense, it's the same thing firefox-nightly does.
>
> --
> Eli Schwartz
> Bug Wrangler and Trusted User
>

Thanks for the reply and info, would you like me to send the
appropriate deletion requests?

Adding a pkgver() to Discord in a clean way is proving to be quite annoying.

Adding this to the source=()
'https://discordapp.com/api/download/canary?platform=linux&format=tar.gz'
causes makepkg to download a file named
'canary?platform=linux&format=tar.gz' even though the download output
from curl correctly manages the redirect and displays "Downloading
discord-canary-0.0.49.tar.gz"

I can get the pkgver via curl -sI
'https://discordapp.com/api/download/canary?platform=linux&format=tar.gz'
| grep -Po '(?<=/apps/linux/)[^/]+' but the pkgver is ran after the
download and prepare.

I don't think it's good practise for the pkgver() to need internet anyway.

I can hack together:
_version=`curl -sI
'https://discordapp.com/api/download/canary?platform=linux&format=tar.gz'
| grep -Po '(?<=/apps/linux/)[^/]+'`
source=("$pkgname-$_version::$url")

But then I have a global variable which requires internet which is
probably worse.

Do you know good way to do this that doesn't break the pkgbuild
conventions? Is it worth it to break those conventions and use these
hacks anyway?