chaotic-aur / packages

Read-only mirror of Chaotic-AUR's main repository. Issues and bug reports welcome! 📑
https://gitlab.com/chaotic-aur/pkgbuilds
GNU General Public License v3.0
335 stars 19 forks source link

[Request] java11-openjfx #2733

Closed bphd closed 1 year ago

bphd commented 1 year ago

Package: java11-openjfx

Package: java11-openjfx Purpose: java11-openjfx is a Java library that provides JavaFX, a software platform for creating and delivering desktop applications. Benefits: This package provides access to JavaFX for applications that require graphical user interfaces. It's useful for developers creating cross-platform desktop applications. Building: To build the java11-openjfx package, follow these steps in a clean chroot:

git clone https://aur.archlinux.org/java11-openjfx.git
cd java11-openjfx
makepkg -si

Copyright: Custom License Expected Interest: Moderate interest among Java developers. Already available? Available on AUR but not on Chaotic AUR. Unique request? Yes, this request is unique and not available on Chaotic AUR. Banned package? Not a banned package. More information: java11-openjfx provides JavaFX support for cross-platform desktop applications, enhancing the user interface and user experience.

xiota commented 1 year ago

In addition to https://github.com/chaotic-aur/packages/issues/2731#issuecomment-1685301021 and https://github.com/chaotic-aur/packages/issues/2732#issuecomment-1685298000:

  1. Why do you need java11-openjfx? Extra already has java-openjfx and java17-openjfx, as well as multiple versions of openjdk, including jdk11-openjdk and jre11-openjdk.
bphd commented 1 year ago

Because I need effects, and not runtime environment or development kit. And I need eleven, not seventeen. If I modify the pkgbuild of what needs it, it will not compile, and I will differ from AUR, needing me to personally maintain the package, creating an alternative package-jre17-openjdk or something and not having automatic build/update of the dependency. Having to create a new repository, or locally build manually or become a valid aur maintainer and being accepted to create a package just for a different depedency. Anyway, why having to justify if people download the package? It's good enough if it's used, no need to make a dissertation justifying selfone

xiota commented 1 year ago

I need eleven, not seventeen. If I modify the pkgbuild of what needs it, it will not compile...

What program or project requires this and won't work with other versions?

Anyway, why having to justify if people download the package? It's good enough if it's used, no need to make a dissertation justifying selfone

Up until now, no one has downloaded the package from chaotic repositories. Since it's not downloaded, it can't be used. Since it's not used, there is no need to add it.

FabioLolix commented 1 year ago

This have a makedepends on gradle7 https://aur.archlinux.org/packages/gradle7

java11-openjfx licenses are a mix of open licenses as the other openjfx packages

gradle7 license is Apache (2.0)

bphd commented 1 year ago

from chaotic repositories.

If people use/download it on AUR

xiota commented 1 year ago

You could save some time by naming the packages you use that require this.

I prefer not to add dependencies without dependents. It increases maintenance burden without any benefit.

bphd commented 1 year ago

If you have a moment, I'd really appreciate it if you could take a look at the dependencies chain and observe the number of downloads for both the dependencies and their dependents. I've taken the time to provide a lot of information that might seem readily available online through normalized URLs, but it's available here for reference. If a particular item is being downloaded and utilized, wouldn't it be great to extend some support to it? After all, the very purpose of this repository is to make valuable packages accessible to everyone who needs them. Your consideration would mean a lot. Thank you!

bphd commented 1 year ago

What program or project requires this and won't work with other versions?

Sure, I'd be happy to help explain this!

In the world of software development, there are various projects and programs that utilize specific versions or builds of libraries and dependencies. One example is when a program includes a reference to a particular version of a library in its "pkgbuild". This is done to ensure compatibility and stability, as different versions of libraries might have changes that could impact how the program functions.

It's important to note that the decision to use a particular version is often made by the maintainers of the project or program. They have taken the time to carefully assess the compatibility and performance aspects of different library versions, and they choose the one that best suits their needs. This process involves testing and consideration of various factors.

While I might not have an exhaustive understanding of every piece of code and its dependencies, I fully respect the efforts put in by the maintainers. They are the experts in their respective domains and have made informed decisions based on their knowledge and testing.

If anyone has concerns or questions about the choices made by the maintainers, there are usually channels available to communicate with them. It's a collaborative community, and feedback is often welcomed. However, it's important to approach these discussions with a sense of understanding and respect for the work that has gone into the decision-making process.

In the end, the diversity of perspectives and the willingness to engage in constructive conversations contribute to the growth and improvement of software projects.

xiota commented 1 year ago

The purpose of items on the request form is to save maintainers' time. By not providing the requested information and being argumentative, you are wasting maintainers' time. I am not asking for general explanations that may or may not apply to any package or user. This request was opened by a specific person for a specific package. In this context, the requested information should apply to that specific package and user.

If you are unable or unwilling to provide the requested information, this request is unlikely to be approved for the reason I've already stated. Adding dependencies that do not have dependents increases maintenance burden without providing any benefit.