FS#80289 - [kde-development-environment-meta] move depends list inside package() function
Attached to Project:
Arch Linux
Opened by - (xiota) - Saturday, 18 November 2023, 19:23 GMT
Last edited by Toolybird (Toolybird) - Sunday, 19 November 2023, 20:01 GMT
Opened by - (xiota) - Saturday, 18 November 2023, 19:23 GMT
Last edited by Toolybird (Toolybird) - Sunday, 19 November 2023, 20:01 GMT
|
Details
Installing all of the (recursive) depends for this
metapackage requires 4389 MiB. Since this metapackage does
not need depends to actually be installed during build, they
should be listed inside the `package()` function. This will
prevent unnecessary bandwidth and resource use when building
in a clean chroot.
This scenario is described in the ArchWiki entry PKGBUILD: 4.1 depends An array of packages that *must be installed* for the software *to build* and run. Dependencies *defined inside* the `package()` function *are only required to run* the software. |
This task depends upon
Closed by Toolybird (Toolybird)
Sunday, 19 November 2023, 20:01 GMT
Reason for closing: Upstream
Additional comments about closing: Refer comments
Sunday, 19 November 2023, 20:01 GMT
Reason for closing: Upstream
Additional comments about closing: Refer comments
I now see that the other KDE -meta pkgs set up the deps inside the various *_package() functions so your point is valid. Sorry for my misunderstanding!
No problem. Thanks for revisiting and reopening.
Please submit a pull request there if you want this implemented.
Arojas: Why didn't you open an upstream merge request? KDE is hostile to new users, especially when they open MRs. Since you have successfully worked with them in the past, a MR from you would be considered more favorably. Also, as the task was assigned to you, isn't it your responsibility to do at least that much to complete it?
Because I don't consider this important enough to spend time on it. My time is limited and my Arch todo list is long enough already.
> KDE is hostile to new users, especially when they open MRs
First time I hear that.
> Also, as the task was assigned to you, isn't it your responsibility to do at least that much to complete it?
This is not a bug. There is nothing wrong with the current PKGBUILD, and it follows the exact same format as other PKGBUILDs. It will make zero difference for building the package on Arch since devtools installs runtime dependencies anyway. So if you want this to be implemented, please submit a PR.
Not wanting to do something doesn't mean it should never be done.
> > KDE is hostile to new users, especially when they open MRs
>
> First time I hear that.
We'll see. I predict first comment to be something like, "Thank you for the MR, but why? What's the point of this?"
https://invent.kde.org/packaging/kdesdk-devenv-dependencies/-/merge_requests/1
https://invent.kde.org/packaging/kdesdk-devenv-dependencies/-/issues/1
> This is not a bug. There is nothing wrong with the current PKGBUILD, and it follows the exact same format as other PKGBUILDs.
That seems to be what Toolybird initially thought before later writing, "I now see that the other KDE -meta pkgs set up the deps inside the various *_package() functions so your point is valid."
> It will make zero difference for building the package on Arch...
Arch isn't the only one who builds these PKGBUILDs.
> ... since devtools installs runtime dependencies anyway.
That's the problem. They're runtime dependencies *only*. They shouldn't be installed *prior* to build. The way to handle the scenario is described at https://wiki.archlinux.org/title/PKGBUILD#depends.
This is the problem right here. Arch only cares about Arch, and rightly so. This is documented all over the Wiki. Anything else is simply not supported. If you think otherwise, then please readjust your thinking. (This reasoning was part of my initial reluctance to assign the issue, it didn't seem like much of a problem for the Arch distro itself).
> as the task was assigned to you, isn't it your responsibility
Sorry, but I have to pick you up on this point, because it's completely wrong. Please review the guidelines, especially this section [1]
Anyway, thanks for raising it upstream. I didn't initially pick up on the fact that it was generated upstream. Please continue to liaise with upstream then once committed we will inherit the changes.
[1] https://wiki.archlinux.org/title/Bug_reporting_guidelines#Upstream_or_Arch%3F