[SOLVED] Viability of AUR packages that don't download...

Bink · 2025-03-24 00:54:27

I've reviewed the AUR submission guidelines and Arch package guidelines, and have not found a guideline for how to best handle this issue, except perhaps this section in the Arch package guidelines > package etiquette:

All important messages should be echoed during install using an .install file. For example, if a package needs extra setup to work, directions should be included.

The davinci-resolve-studio package (and davinci-resolve) does not download the source file. From Jan 26 2025 onward, the new package maintainer removed the direct links to the source files from the PKGBUILD, which results in a failed build:

$ makepkg -sri

==> Making package: davinci-resolve-studio 19.1.4-1 (Mon 24 Mar 2025 11:39:16)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Downloading DaVinci_Resolve_Studio_19.1.4_Linux.zip...
curl: (3) URL rejected: Bad file:// URL
==> ERROR: Failure while downloading file://DaVinci_Resolve_Studio_19.1.4_Linux.zip
    Aborting...

There is no output here providing instructions to users, so the package simply feels broken.

The maintainer has however, included instructions in the PKGBUILD:

# Get the source file DaVinci_Resolve_Studio_${pkgver}_Linux.zip from:
# [url]https://www.blackmagicdesign.com/support/family/davinci-resolve-and-fusion[/url]
# and save it in the same directory of this PKGBUILD

And at the davinci-resolve-studio AUR page:

IMPORTANT!
Since version 19.1.3-2 this package will not download automatically the source file from the upstream site.
To build this package you will need to manually download the file from https://www.blackmagicdesign.com/suppor … and-fusion and place it in the same directory with the PKGBUILD.
This would reduce the mess in this package, making it more readable and clear. Also bypassing the required information from the upstream URL is not allowed in an automated way.

I'd like to note, the claim that "bypassing the required information from the upstream URL is not allowed in an automated way" remains unverified. Blackmagic were asked to verify this claim in January and have remained silent.

As a matter of personal opinion, I believe there are better ways these issues can be handled. Might there be reasonable need to clarify best practice?

Last edited by Bink (2025-03-26 01:23:29)

mackin_cheese · 2025-03-24 06:14:30

well if the upstream itself is preventing direct automated download, would you rather have the community lose out on the ability to have davinci managed by pacman? what better ways to handle this did you have in mind?

Last edited by mackin_cheese (2025-03-24 06:15:13)

seth · 2025-03-24 08:17:58

All important messages should be echoed during install using an .install file. For example, if a package needs extra setup to work, directions should be included.

refers to actions concerning the installation of the package, *after* it has been built (which is the critical step here)
https://wiki.archlinux.org/title/PKGBUILD#install

Instead of the SOURCE array, the prepare/build function could check for the existence of the source and state the requirement there instead of (only) in the PKGBUILD comment - you're expected to read the PKGBUILD before running makepkg, but skipping the comments might be rather common even for users who actually do read the PKGBUILD.

That being said, using file://something as source is perfectly valid and not uncommon for PKGBUILDs that cannot fetch the data from a public source source (eg. proprietary game data or whatever) - whether that legally applies here, I've no idea and it ultimately is the packages maintainers call - either for legal concerns or because it's too tedious to keep track or the source location (Muflone is probably more of a technical than interested maintainer and w/o maintainership the package would get wiped from the AUR entirely)

Muflone · 2025-03-24 08:53:32

Bink wrote:

As a matter of personal opinion, I believe there are better ways these issues can be handled.

What are these better ways, in your personal opinion?

Bink · 2025-03-24 12:07:44

mackin_cheese wrote:

well if the upstream itself is preventing direct automated download, would you rather have the community lose out on the ability to have davinci managed by pacman?

I believe it is possible to automate download, provided it's the latest release you're trying to download. Previous releases stop working. This is working in my testing:

wget -O DaVinci_Resolve_Studio_19.1.4_Linux.zip https://swr.cloud.blackmagicdesign.com/DaVinciResolve/v19.1.4/DaVinci_Resolve_Studio_19.1.4_Linux.zip?verify=1742814107-JfFOmPXtPUw0nA1CkZLKXUaBxZJB%2F%2Bm0EGoejoQfWvo%3D

Muflone wrote:

Bink wrote:
As a matter of personal opinion, I believe there are better ways these issues can be handled.
What are these better ways, in your personal opinion?

I appreciate you asking. A better way, if there even is a viable one, would of course depend on some of the details and I acknowledge that I may be ignorant of these, despite efforts to garner some details from BlackMagic. This statement and understanding it is important:

"Also bypassing the required information from the upstream URL is not allowed in an automated way."

Upstream being Blackmagicdesign.

Is this something Blackmagicdesign has explicitly stated, or
Is this something that has so far only been assumed?
Is it because of the added maintenance overhead of discovering the download link every update?

If a: Something Blackmagicdesign has explicitly stated

Is there an existing dialogue with Blackmagicdesign?

I encountered a similar issue with a package that I maintain, the Harman air-sdk (previously Adobe). I first reached out to the Harman team, to confirm creating an AUR installer wouldn't be an issue. They warmly made it clear to me that an installer must not circumvent the license information provided on their website download page. Fairly quickly we found a compromise we were all happy with, which was to present users with a link to the Harman license agreement and prompt the user to accept those terms, before the source file would download. All of this is managed in the air-sdk PKGBUILD file.

The air-sdk is one example I offer of a package that has no defined source property, but will download the source for the user if a condition is met.

Additionally, if Blackmagicdesign have been explicit and will not budge on the issue, then the same technique with conditional logic could be used to guide the user when the source file isn't already present in the package directory.

If b: Something that has so far only been assumed

I would encourage an attempt at dialogue with Blackmagicdesign confirm and hopefully work towards a happy compromise. If they remain unresponsive and the question is still in the air, then perhaps it's time to beg for forgiveness later, rather than ask for permission. There would have been a genuine attempt to do things right after all.

If c: The added maintenance overhead of discovering the download link every update

@Mulfone, you are clearly a busy person when it comes to maintaining AUR packages, with an exhaustive list of over 300 under your name. I would completely respect and understand the need to simplify the process. I would suggest as such, considering a co-maintainer for the davinci-resolve packages, one who is happy to invest the extra time to discover the download links when they change with each update. I don't presume to be your first choice, but I'd be happy to be considered if this is an option you believe is viable. I'm an invested Davinci Resolve Studio user, and maintainer of a small handful of AUR packages already.

Last edited by Bink (2025-03-24 12:16:10)

Lone_Wolf · 2025-03-24 12:15:51

Fairly quickly we found a compromise we were all happy with, which was to present users with a link to the Harman license agreement and prompt the user to accept those terms, before the source file would download. All of this is managed in the air-sdk PKGBUILD file.

PKGBUILDs should not require any user input, if you don't change it someone may request deletion of that package.

Bink · 2025-03-24 12:22:35

Lone_Wolf wrote:

Fairly quickly we found a compromise we were all happy with, which was to present users with a link to the Harman license agreement and prompt the user to accept those terms, before the source file would download. All of this is managed in the air-sdk PKGBUILD file.
PKGBUILDs should not require any user input, if you don't change it someone may request deletion of that package.

@Lone_Wolf, could you please point me to the guidelines on this one?

seth · 2025-03-24 13:19:23

https://wiki.archlinux.org/title/Creati … _variables - 2nd blue note
Whatever the preferrable handling of such issues might be, manual intervention during the build isn't ideal and should™ not be mandatory.

----

As a matter of personal opinion, I believe there are better ways these issues can be handled.

What are these better ways, in your personal opinion?

I believe it is possible to automate download

That's not an alternative approach, that's the dismissal of the assertion that

This would reduce the mess in this package, making it more readable and clear. Also bypassing the required information from the upstream URL is not allowed in an automated way.

there's an issue tbw.

For my 2¢ I'd say that the presence of a verification token is a strong indicator that upstream might not be ok with this.
But it's also not bound to an IP or (apprently) time-limited so as long as they don't complain I'd not consider it an obstacle either.

mackin_cheese · 2025-03-24 13:47:12

until the information tied to that verification token gets blacklisted due to download abuse lol

seth · 2025-03-24 13:51:07

What would then at least clarify the situation.

mackin_cheese · 2025-03-24 14:03:50

seth wrote:

What would then at least clarify the situation.

not sure if that was a question or a statement due to the wording but yeah if upstream is requiring that information, we should be respecting that decision. Circumventing that with a link that has a verification token should be a concern. I think the AUR guidelines might need to be updated to include that PKGBUILD should not include a method to circumvent requirements that have been placed by the upstream, this will satisfy OP's concern. I think it should be included in the guidelines in my opinion, due to the AUR being managed by ArchLinux

Bink · 2025-03-24 14:11:46

seth wrote:

https://wiki.archlinux.org/title/Creati … _variables - 2nd blue note
Whatever the preferrable handling of such issues might be, manual intervention during the build isn't ideal and should™ not be mandatory.

The note at the link:

Note: makepkg, and thus the build() and package() functions, are intended to be non-interactive. Interactive utilities or scripts called in those functions may break makepkg, particularly if it is invoked with build-logging enabled (--log). See FS#13214 for details.

Thank you for that link. It noted an issue, and I've run a test build on air-sdk with makepkg logging enabled (--log) and it built without incident. I'll take the Wiki note as a fair caution though, and a principal that user input should at the very last be avoided when it can be done so legally. I'd have to wonder though, if in the 16 years since that issue was discovered, that particular issue might have been addressed?

I'll reach out to the Harman guys again, but as part of their agreement with Adobe, user acceptance of the license agreement needed to be a proactive step. It's a public conversation I can provide links for if the Arch Package Maintainer team would like verification of that.

Some clarity of ruling on the user input question would be welcome. Is user input never ok, or rather enigmatically "intended to be non-interactive"?

Last edited by Bink (2025-03-24 14:13:48)

Bink · 2025-03-24 14:19:54

mackin_cheese wrote:

seth wrote:
What would then at least clarify the situation.
not sure if that was a question or a statement due to the wording but yeah if upstream is requiring that information, we should be respecting that decision. Circumventing that with a link that has a verification token should be a concern. I think the AUR guidelines might need to be updated to include that PKGBUILD should not include a method to circumvent requirements that have been placed by the upstream, this will satisfy OP's concern. I think it should be included in the guidelines in my opinion, due to the AUR being managed by ArchLinux

I agree it would be clarifying, and I agree we should respect upstream decisions.

The question that leads from that though, is if one should not circumvent upstream requirements (fair enough), but upstream gives their ok provided the user interactively accepts an agreement, is that OK with the Arch decision makers?

seth · 2025-03-24 14:29:16

@mackin_cheese the token is an indicator of a guarded link, but not a very strong one.
Usually you have to prove being a human by training some AI for free and then you get a url valid for your IP and the next 60m or so.
That's apparently not the case here (I'm aware that there're batshit crazy court rulings deeming base32 encoding "encryption", but so far we're not at court)

The OP has complained that upstream has not responded to clarify the situation - upstream altering/hardening the access or even explicitly stating "hey! don't do that!" would at least provide that clarity.

@Bink, that would be equivalent to the status quo - your lat question boils down to "is it ok to require manual intervention during the package build" and the answer to that is "preference, but should not"
What "should" happen is that the build fails and it would be nice to at this point write reason and solution to stdout.
But if I have the file in place, the build must just succeed w/o any interaction and not get into the way of competent users.

"intended to be non-interactive" implies that the functions should be designed w/ that in mind and esp. not wait indefinitely for human interaction.

Muflone · 2025-03-24 17:10:33

Bink wrote:

This is working in my testing:

wget -O DaVinci_Resolve_Studio_19.1.4_Linux.zip https://swr.cloud.blackmagicdesign.com/DaVinciResolve/v19.1.4/DaVinci_Resolve_Studio_19.1.4_Linux.zip?verify=1742814107-JfFOmPXtPUw0nA1CkZLKXUaBxZJB%2F%2Bm0EGoejoQfWvo%3D

This link is currently broken for me, leading to a Sorry, you have been blocked page.

This is enough to understand the website operators don't want to offer static reusable links as this would entirely defeat the form for requesting the user information.

Blink wrote:

I would suggest as such, considering a co-maintainer for the davinci-resolve package

Actually there's no need to add co-maintainers to both packages, they were updated in a couple of days but even more importantly, there's no consensus about how to manage these issues, people wanted to keep that crappy request to send false information to Blackmagic to obtain the download link, which is a thing I'm 100% opposite.

Also all the whole discussion about this package seems to me useless, there are hundreds of packages using local files when the download is not predictable or not allowed.

Also this was clearly explained in both PKGBUILD and package comments page.

I'm a software author and whenever I want to ask my users to accept some conditions, including giving me their data, I insist on having my request being fulfilled, not bypassed using weird scripts to provide fake data.

Also Davinci updates are not so frequent

Bink · 2025-03-24 22:26:42

Muflone wrote:

Bink wrote:
This is working in my testing:
wget -O DaVinci_Resolve_Studio_19.1.4_Linux.zip https://swr.cloud.blackmagicdesign.com/DaVinciResolve/v19.1.4/DaVinci_Resolve_Studio_19.1.4_Linux.zip?verify=1742814107-JfFOmPXtPUw0nA1CkZLKXUaBxZJB%2F%2Bm0EGoejoQfWvo%3D
This link is currently broken for me, leading to a Sorry, you have been blocked page.
This is enough to understand the website operators don't want to offer static reusable links as this would entirely defeat the form for requesting the user information.

That the link has now ceased to work is refreshingly clarifying. It helps put things in perspective.

twelveeighty · 2025-03-24 23:45:15

Hardcoding the verification token - the `?verify=1742...` part in the wget - is deliberately circumventing the vendor's agreement with you which allows them to refuse the use of DaVinci if you didn't give them your personal info:

Blackmagic Privacy Policy wrote:

However, some of our services may include a direct marketing and promotional communications feature as part of the Service which cannot be removed and, as such, you may not be able to access or use some of our website or services if you elect to opt-out of all direct promotional and marketing communications.

Bink · 2025-03-25 04:18:18

twelveeighty wrote:

Hardcoding the verification token - the `?verify=1742...` part in the wget - is deliberately circumventing the vendor's agreement with you which allows them to refuse the use of DaVinci if you didn't give them your personal info:
Blackmagic Privacy Policy wrote:
However, some of our services may include a direct marketing and promotional communications feature as part of the Service which cannot be removed and, as such, you may not be able to access or use some of our website or services if you elect to opt-out of all direct promotional and marketing communications.

I'd consider the viability of a direct download link a settled matter, which is to say, it's not viable.

Just as a note though, to legitimately download Davinici Resolve Studio from the official website requires no login information to be handed over, aside from what they might possibly glean from the usual IP and browser fingerprinting. They invite you to provide personal details, but they also provide you the option to skip that and simply download.

seth · 2025-03-25 07:35:44

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

About improving the situation based on the given constraints, no idea whether Muflone is ok w/

if [ ! -e DaVinci_Resolve_Studio_${pkgver}_Linux.zip ]; then
   echo "blahblahblah RTFM!"
   exit 1
fi

to essentially abuse that the PKGBUILD is simply sourced into the makepkg script.

Bink · 2025-03-26 01:30:11

Thank you @seth and @Muflone, for engaging with my topic and taking the time to share your thoughts. The issue is clearer to me now and I've gained more appreciation for the difficulty of the task @Mulfone has.

In light of the limitations imposed by upstream,I think @seth's suggestion to provide some user guidance in the PKGBUILD, is the only proposal left on the table.

Arch Linux

#1 2025-03-24 00:54:27