It's an essential program for musicians that has no alternatives on GNU/Linux and other free OSes.

Sadly, I will not use Parabola because of this single program.

luckily, there is nothing preventing you from using this, or any
program with parabola; and because an AUR PKGBUILD exists, it is
very simple to install it - adding it to parabola repos would
not make much difference, as long as the AUR maintainer updates
it when that is needed

the easiest way for an AUR package to get into parabola is if it
gets votes on AUR - when some AUR package accumulates enough
votes, then arch will consider adding it to the main repos; and
then parabola would get it automatically - this packages has 33
votes, which is significantly more that average - however, if
the package does not build from source, and it is a large amount
of work to make it build from source, then it is likely that
arch would not take it either - furthermore, if that work were
done, and it turns out that any of those dependencies are not
freely licensed, then parabola would need to blacklist it; so
like most java programs, this is probably already the ideal
situation for any parabola users who want to use them

Thanks for your explanation, I think the dependencies under consideration are Apache Maven files that are all available in Apache's Source Repository, and are distributed under the free Apache License v.2.0.

the license of the dependencies is not the entire concern though - each dependency would need to each be packaged separately - unfortunately with java programs, that often numbers in many dozens - that is a large number of packages that would need to be maintained only to support one program

if most of those dependencies were widely used by other programs, then that would increase the value of maintaining them; but that could introduce a bigger problem because java developers are not thinking in terms of stable distros with standard libraries - different java programs would be likely to depend on different (possibly incompatible) versions of the same library; which could make some of them exponentially more difficult to support

that is the reason devs that use non-native languages (like java, golang, C#, javascript, ruby, python) most often package "the kitchen-sink" and require any user who wants to build from source to install every dependency to a writable location (or worse, to a system location) using the language-specific package manager, or they put everything in a much larger container package to overcome the fragility of this user-install method - those approaches are much simpler for the developers because it allows devs to pile on dependencies liberally, with little or no concern for efficiency, compatibility, or code simplicity; but imposes a large and fragile overhead onto the user and down-streams

that sort of development practice is the polar opposite of, and induces great friction with, what distros do on behalf of users in order to keep their system efficient and sane - its the very reason why distros exist in the first place - developers using non-native languages are predominantly users of proprietary operating systems that do not have proper package management, and who do not prioritize simplicity and efficiency which are the key tennents of "the UNIX philosophy" and the hallmarks of an arch distro

sure, these things could be packaged; but that there are relatively few java, golang, or C# programs that are widely used by users of nix distros; which makes the dependencies of each such program, more rarely used, and therefore less valuable to a distro or its users - python and haskell are the exceptions (and to a smaller degree, ruby and javascript), mainly because they are more widely used in the system tools of nix distros and they do not need to be compiled; which makes packaging and maintenance less work - as such, most of the commonly used dependencies for python and haskell have been packaged already

that is a long-winded explanation; but for anyone interested, it is why you do not see very many java, golang, or C# programs in any distro - it probably also explains why such an "essential program for musicians" is in the AUR and not in arch already - there is now a pro-audio team for arch, which added a large number of audio production programs last year - if this were to happen, it would be best discussed on the 'arch-proaudio' mailing list - i invite you to ask about ths program on that mailing list - the lead dev of the 'arch-proaudio' team is very libre-minded; and we should work closely with them in regards to any audio production software

https://lists.archlinux.org/listinfo/arch-proaudio

Oh, you wrote a whole essay..
As far as I know, only 3 Maven plugins are needed for TuxGuitar, maven-install-plugin, maven-dependency-plugin, and maven-ant-plugin.

bill-auger perhaps didn't give a clear enough example. and from your above comment it's clear that you haven't tried building it yourself.
Because as soon as the build phase of makepkg starts it looks like this.

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building tuxguitar-pom 1.5.2_r1800
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ tuxguitar-pom ---
[INFO]
[INFO] --- maven-install-plugin:2.4:install (default-install) @ tuxguitar-pom ---
Downloading: https://repo.maven.apache.org/maven2/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.pom
Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/maven-profile/2.0.6/maven-profile-2.0.6.pom
Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/maven-artifact-manager/2.0.6/maven-artifact-manager-2.0.6.pom
Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/maven-repository-metadata/2.0.6/maven-repository-metadata-2.0.6.pom
Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/maven-artifact/2.0.6/maven-artifact-2.0.6.pom
Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/maven-plugin-registry/2.0.6/maven-plugin-registry-2.0.6.pom
Downloading: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/3.0.5/plexus-utils-3.0.5.pom
Downloading: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus/3.1/plexus-3.1.pom
Downloading: https://repo.maven.apache.org/maven2/org/sonatype/spice/spice-parent/17/spice-parent-17.pom
Downloading: https://repo.maven.apache.org/maven2/org/sonatype/forge/forge-parent/10/forge-parent-10.pom
Downloading: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-digest/1.0/plexus-digest-1.0.pom
Downloading: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-components/1.1.7/plexus-components-1.1.7.pom
Downloading: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus/1.0.8/plexus-1.0.8.pom
Downloading: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-container-default/1.0-alpha-8/plexus-container-default-1.0-alpha-8.pom
Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/maven-project/2.0.6/maven-project-2.0.6.jar
Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/maven-profile/2.0.6/maven-profile-2.0.6.jar
Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/maven-plugin-registry/2.0.6/maven-plugin-registry-2.0.6.jar
Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/maven-settings/2.0.6/maven-settings-2.0.6.jar
Downloading: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-container-default/1.0-alpha-9-stable-1/plexus-container-default-1.0-alpha-9-stable-1.jar
Downloading: https://repo.maven.apache.org/maven2/junit/junit/3.8.1/junit-3.8.1.jar
Downloading: https://repo.maven.apache.org/maven2/classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2.jar
Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/maven-artifact-manager/2.0.6/maven-artifact-manager-2.0.6.jar
Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/maven-repository-metadata/2.0.6/maven-repository-metadata-2.0.6.jar
Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/maven-artifact/2.0.6/maven-artifact-2.0.6.jar
Downloading: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/3.0.5/plexus-utils-3.0.5.jar
Downloading: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-digest/1.0/plexus-digest-1.0.jar

We, the devs whould have to track every one of those down. check the licensing package then, patch the build to use our packages rather then pull willy nilly from the Internet.
On top of that there'd be the version headaches he mentioned. Etc. Etc. This is just a bad fit from a maintenance/freedom standpoint.

Thanks for clarifying it, you're right, there's plenty of them, at least we know it's all Apache files. And no, I didn't build it myself, I took a quick glance at its build scripts, I'm not on a *nix system currently.

An understandable mistake. One shouldn't have to anticipate that the process of compiling code would result in it downloading a bunch of stuff. But sadly in a world of Java/Go/Rust/Ruby/etc it is something you have to actively watch for.

AuroraBorealis -

just to make it clear again, that using parabola would not prevent you from using this program - the very point of a free OS is that it does not prevent you from doing anything, including running proprietary software - the only implication is that you would need to build for yourself the packages that parabola does not carry - luckily, that is quite simple to do if someone in AUR has done the hard work already

and BTW i did not mind writing an essay on this topic - it comes up often enough that i have myself, explained this in much the same way several times - spelling it out into such detail in a published form, is an investment for the future - the next time this comes up, that verbose comment may become the seed of a wiki article, so that i, and other parabola devs, wont need to explain it again in full

it seems that you guys have a great community here.. I didn't expect to see such comprehensive input and readiness to assist on my humble request page.

in a case like this, urgency is no longer an issue at all, unless this program has some useful functionality that no other program in the parabola repos can accomplish

the main consideration for adding a new package is the desirability/cost-of-maintenance ratio - we have seen that the cost-of-maintenance factor is quite high for this one; so its desirability factor would also need to be very high to make it valuable - if musescore does the same job as tuxguitar, that decreases the desirability factor of tuxguitar significantly