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

[Robin Broda]

On 05/10/2018 05:23 AM, Morgan Adamiec via aur-general wrote:
> 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.

This is kind of a TOCTOU issue. I wouldn't recommend it.

> 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?
> 

Does the tarball not contain any version information at all?

Rob