On Thu, 19 Mar 2026 23:21:40 +0000 Polarian <polarian@polarian.dev> wrote:

This package is maintained by an Arch Developer, end of story.

That's a very strange reasoning. I think there's a confusion here between a factual argument and an authoritative one. -- Marek Küthe m.k@mk16.de er/ihm he/him

Hey, Let me put it more clearly then, Muflone is the main staff member who moderates the AUR, I can assure you they know the rules inside out. They have already explained their reasoning for the change. [1] There is literally nothing to discuss here, other than "I disagree with the change". If you have an issue with it you should probably bring it up with Muflone, not subject an entire mailing list to your personal preferences. In any case, this is not a hill worth dying on. You have an extra step which is clearly documented [2]. If you want to take your anger out on someone, maybe take it out on Black Magic Design which forced this change, Muflone has already concluded this a year ago [3], you are blaming the wrong person here. There is no stable URL to download the sources from and forcing people to run ambiguous scripts is a security threat, malicious PKGBUILD's have happened before, therefore you must always review what you are building which, as Muflone has pointed out, can not be done if there is a hacky workaround which is not possible for the average user to review. I am aware that davinci is much more advanced than a lot of the open source competition but if it is such a big deal, maybe give some open source alternatives a go, ones which actually give you both software freedom, and can be properly packaged and distributed, without upstream causing any issues, unlike resolve. Thank you, -- Polarian Jabber/XMPP: polarian@icebound.dev [1] https://aur.archlinux.org/packages/davinci-resolve?O=60#comment-1013733 [2] https://wiki.archlinux.org/title/DaVinci_Resolve [3] https://aur.archlinux.org/packages/davinci-resolve?O=60#comment-1009644

I'll just throw in my 2 cents.

A package is an archive containing: all of the (compiled) files of an application metadata about the application, such as application name, version, dependencies, etc. installation files and directives for pacman

[https://wiki.archlinux.org/title/Pacman#Installing_packages] Obviously this does not apply to AUR packages in the same way, because the source files are usually stored in an external repository. However, for the user, the installation flow is the exact same as if the package contained the source files. To expect the user to download the actual file is too far; what you have then is not a package, but an installation script. I think there is an argument to be made that davinci-resolve is unpackageable under a strict interpretation of the AUR guidelines. I'm not averse to the old implementation of the package, though, because it was still a package. Also, can we please have plaintext emails? Sam

I'm going to retract what I said earlier about the old package design being acceptable. We should not try and circumvent intentional Blackmagic design, whether it's technically permitted by the TOS or not.

Therefore, strictly speaking, according to AUR guidelines, the package shouldn’t be available in any other form.

I agree. To be honest, I don't see that the package is currently adding enough utility beyond a manual installation to warrant being a package in the first place.

Having to locally download files shouldn't be breaking behavior for a user when using AUR Packages as best practice expects the user to confront themselves with the content of the PKGBUILD anyway. This includes to take notice of additional requirements such as the file that is locally required. One can expect so much effort to put in by the user.

Well, the AUR package is still supposed to be a package right? I feel like the fact that users should read a pkgbuild isn't an excuse to insert additional friction into the package. AUR packages are supposed to have some utility, otherwise they wouldn't exist.

What I would suggest is that someone with “clout” in the Arch Linux community (at least someone with an `@archlinux.org` email address) get in touch with Blackmagic Design and explain the situation

+1. Alternately maybe it can be Muflone who writes the email, but in general I think this is a good idea. Sam

El sáb, 21-03-2026 a las 20:42 +0100, Muflone escribió:

AUR is not officially supported by Arch Linux, and no packages on AUR can be sponsored by Arch Linux or are part of the Arch Linux project. Since I do not intend to move DaVinci Resolve and DaVinci Resolve Studio packages to the official Arch Linux repositories, I will not be sending any official requests to Blackmagic, either via my @archlinux.org email address or my personal email addresses.

But you can explain exactly what you just mentioned, Muflone: I’d like to package your software in the AUR. The AUR is this (and you explain what it is), and the reason I can’t get the package into official repositories is the one you mentioned. What do you have to lose by trying? You’ve already heard “no,” but maybe you’ll succeed. I myself have contacted developers of various projects in the past to see if they could tweak something just a little so I could easily get it into the AUR, and they’ve all been grateful to me for it. Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me

Hey, Will heap my responses into a single email.

As another staff member who moderates the AUR (though not as often as Fabio), discussion of changes is fair game for this mailing list.

Changes to what? Either: 1. Make the PKGBUILD impossible to audit by the average person, well that would be a security concern. 2. Lobby for upstream to provide a stable URL, or even go as far as was done with Discord (seen as Muflone is staff) and see if Arch can get written permission to redistribute resolve as a package. Other than that, I do not see what possible outcomes there are to discuss.

You're coming at this from a much more aggressive position than the OP. There's no indication that OP intends to die on this hill—they simply want to discuss the change and whether it could potentially be revisited

I meant no aggression. The reason I used "die on the hill" because I don't see how fetching one file manually is a big enough deal that it warrants a whole new discussion on a discussion which (as I quoted in the previous email) had already been done on the AUR comment section.

I don't see anything wrong with that given the way they've presented their arguments. The worst we can say is that we won't change it back.

Never said anything was wrong, just their argument is directly towards the wrong person. I don't see what Muflone is meant to do, either you compromise on security or you fetch it yourself. I don't think anyone here is going to say the former is the better option.

A fair point, but as you've admitted, Resolve is much more advanced than the likes of Shotcut, Kdenlive, etc. If you want a professional video editor the likes of Premiere or Sony Vegas on Linux, you need Resolve. That's not to knock the FOSS competition in any way, it's just reality.

Indeed. Although kdenlive to my knowledge has become a competitive choice when it comes to video editing (disclaimer I am not a video editor, this comes purely from discussions with those who are).

Polarian, I'd like to remind you—as I know others have in the past—you are not an AUR moderator. You've engaged in what's called "armchair moderation" here, where someone with no power to enforce rules attempts to do so anyway.

I have no desire to "enforce rules". As with everyone else subscribed to the mailing list I have the ability to reply to emails. I think you have gotten the wrong intent of the email. My previous email was literally pointing out that the entire discussion had already been done previously, and cited the comments, there was no intent of moderation there.

If you're going to engage in this discussion—and you should feel free to do so—please do so constructively and without speaking for the Arch staff members that are fully capable of speaking for themselves.

I didn't? I pointed out that Muflone was a staff member and thus fully understood the rules. There is a difference between the average AUR maintainer and a staff member who regularly rules on AUR requests. I wasn't speaking for Muflone, I was pointing out the AUR package is maintained by someone who is well know. I did cite his comments, to show that this discussion was already discussed and ruled on. I think you have completely misunderstood the intent of my email, I was simply trying to help by pointing out what had already been discussed, not trying to moderate in any way.

Obviously this does not apply to AUR packages in the same way, because the source files are usually stored in an external repository. However, for the user, the installation flow is the exact same as if the package contained the source files. To expect the user to download the actual file is too far; what you have then is not a package, but an installation script.

The AUR doesn't provide packages, they provide build scripts for packages. The only annoyance with this is that you cant use AUR helpers, but Arch doesn't support these anyways so there's no basis for argument that breaking AUR helpers would violate the rules.

I think there is an argument to be made that davinci-resolve is unpackageable under a strict interpretation of the AUR guidelines.

Arch Linux is pragmatic, so there should be no "strict interpretation" they are more guidelines. A PKGBUILD for resolve is better than nothing, even if it needs manual intervention.

I'm not averse to the old implementation of the package, though, because it was still a package.

No it is a build script, used to build a package. All the removed changes did was bypassed the annoyances upstream, but as explained numerous times doing so was difficult to audit, and the average user, because AUR is build scripts NOT a package, needs to be able to audit the PKGBUILD before building it, otherwise its a security threat.

One thing I could maybe see being done here is approaching Blackmagic Design directly in a diplomatic manner to find a solution to optimizing this, but since the primary goal of Blackmagic Design seems to be the identification of it's users, I am not optimistic about how and if we had could come to compromise there. If anything, Muflone as the package maintainer is probably the most qualified in assessing if such an approach would be useful and to have said conversation.

This is usually done by Arch staff (which Muflone is) and it could indeed be beneficial for an official email to be sent to blackmagic, like done with Discord. Potentially allowing for not only a stable URL for source downloading, but also permission to redistribute resolve, allowing it to be pulled into the repositories in the future. If Muflone is around maybe they can comment on this, otherwise maybe someone should ask them directly if they have attempted this yet?

I apologize in advance when I messed up to answer to this thread, since I am new to using mailing lists.

Your reply is good, and I fully agree.

The download procedure through the support center and through the main page is identical. The form is always required for the free version, and always optional for the paid one. The support center provides access to older versions of the software (and other, auxiliary software, like Fusion standalone or the control panel setup tooling). I’m certain that Blackmagic doesn’t mind people using it; as I stated before my primary reason for going there is acquiring older, more bug-free software versions

You have missed the point made again. I do agree that working around the restrictions put in place by blackmagic is wrong, but the bigger issue here is the security implications of a complicated script which must be used to bypass blackmagic, which the average user cannot audit and thus can't be sure the PKGBUILD is not malicious. Unless there is a easy URL to get the distributable from, the safest option is what Muflone has already done, which is to require manual intervention (download the distributable manually). I agree, this is not ideal, but security comes first, and there is an argument also to be made of not causing issues upstream by bypassing what blackmagic has put in place. The tradeoff is massively outweighed by the benefits in this case, and thus I still don't see what there is to discuss here.

Either way, I do understand the concerns with violating Blackmagic’s TOS and license agreements, but I haven’t read them, so I cannot tell you.

That is an additional point you are still missing the main point, it is a security concern. The PKGBUILD IS NOT a package, and must be reviewed by the average user. Most users do not have indepth knowledge of shell scripting and thus the bypass can't be audited by the average user.

I was doing this for some time, but it’s effectively more effort (especially when trying to keep up with fixes to the upstream PKGBUILD) than downloading the package manually from Blackmagic’s website in the first place.

How long does it feasibly take to download the distributable from upstream? 1 minute? In contrast, say if you poorly audited a PKGBUILD and it wiped your user home directory, how long would that take to recover from? Security matters far more here. Take care, -- Polarian Jabber/XMPP: polarian@icebound.dev