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 > <[email protected]> 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
