Re: [arch-dev-public] Library dependencies
On 16/12/21 13:24, Xyne via arch-dev-public wrote: On 2021-12-15 16:40 +1000 Allan McRae via arch-dev-public wrote: The dependencies added are purely sonames that the binary are explicitly linked to. So the binary will be non-function without libraries providing that exact soname. Thus all these dependencies are necessary. Of course it will be up to the distribution to decide how much they use this feature - should all libraries provide their lib:soname value or just some? Dependencies are only added if there is a relevant provide. What happens if a package includes "optional" binaries that depend on optdeps? Do those become hard deps? Assuming that dependent library is not used elsewhere in the package, and the extra library had a provide of its library version, then this would add an extra dependency. There are several options: 1) disable autodeps - these really do not need used everywhere... 2) split the package 3) move the binary into /usr/lib/ and add a symlink to /usr/bin. Then (assuming BIN_DIR=usr/bin is the usual search path), the dependency would not be added. Saying that, I am against optional dependencies that are genuinely needed for a binary to run. I think these should be used for features that could be dynamically loaded if the optional dependency is present. I prefer package splitting if that is not the case. As for extending this to other dependency types such as commands, I wonder if cmd:name would be specific enough. It's rare but sometimes unrelated commands can have the same name. Some sort of unique identifier may be required. I only mention it in case it should be considered for generalizing the syntax now before settling on a final format. Possibly something like "prefix:identifier/object", where "identifer/" is optional. So you would have "cmd:unique_cmd" for something unique but "cmd:foo/common_cmd" for some generic fungible common_cmd provided by different packages when a conflicting common_cmd exists in another package. I don't see why we can not have multiple packages provide the same command. We already have multiple packages with the same provides entry, just with a package name and not a command name. You can have multiple packages that provide the same command, but there may be rare cases where two conflicting packages provide unrelated commands with the same name, or a restricted version of a command that may not support the full argument set. It's worth considering how to handle such cases now before settling on a syntax. Do you have an example? I don't like adding complexity for "what if" cases that may never occur. For the case you described, cmd:foo is provided by two packages, foo1 and foo2. foo2 has a subset of the functionality. Then you could depend on cmd:foo if either works, or foo1 if you need the full functionality. How would this syntax work for optional deps btw? Also, if this is added, it would be useful to have an option to display the provider package of such deps in the output of pacman -Qi (e.g. -Qii). For optdeps, what I mean is if the normal dependency would be "lib:libgpgme.so.11", how will you parse the normal optdep syntax of "pkgname: reason"? "lib:libfoo.so.13: required for the command foo". Won't using the same delimiter in two different contexts be problematic? From memory, the space in ": " is important for optdepends. I need to check, but I don't think the PKGBUILD linter will let PKGBUILDs with optdepends without the space build. And pacman will not split the string without it. So this should be fine. Allan
Re: [arch-dev-public] Debug package support in dbscripts
Reminder! repos.archlinux.org is unavailable in 30 minutes. On 14/12/2021 21:22, Jelle van der Waa wrote: Hi All, Foxboron has been working on support for debug packages in dbscripts the past year. The progress has been slow but we are at a stage where we want to deploy the dbscripts portion of this. That means that on Thursday 17:00 until 20:00 UTC+1 we will close down repos.archlinux.org for any package updates. The idea is to try limit any potential unforseen bugs and have a small testing phase before opening it like normal. If we do find bugs we will rollback any changes and work out the bugs. If everything goes according to plan we’ll work on a devtools patch that would allow debug package updates. Then it is up to us if we enable debug for all packages or make it opt in. If people are curious about the introduced changes, they can be found here: https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/21 The original proposal from November last year can be found here: https://lists.archlinux.org/pipermail/arch-dev-public/2020-November/030222.html Cheers, Foxboron & Jelle
Re: [arch-dev-public] Debug package support in dbscripts
Hi All, On 14/12/2021 21:22, Jelle van der Waa wrote: Hi All, Foxboron has been working on support for debug packages in dbscripts the past year. The progress has been slow but we are at a stage where we want to deploy the dbscripts portion of this. That means that on Thursday 17:00 until 20:00 UTC+1 we will close down repos.archlinux.org for any package updates. The idea is to try limit any potential unforseen bugs and have a small testing phase before opening it like normal. If we do find bugs we will rollback any changes and work out the bugs. If everything goes according to plan we’ll work on a devtools patch that would allow debug package updates. Then it is up to us if we enable debug for all packages or make it opt in. If people are curious about the introduced changes, they can be found here: https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/21 The changes have been deployed on repos.archlinux.org, everything should work as expected. If you encounter issues please report them either in this mail thread or on #archlinux-devops on libera.chat Thanks advance, Jelle van der Waa OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] Debug package support in dbscripts
On 2021-12-16 20:50, Jelle van der Waa via arch-dev-public wrote: Hi All, On 14/12/2021 21:22, Jelle van der Waa wrote: Hi All, Foxboron has been working on support for debug packages in dbscripts the past year. The progress has been slow but we are at a stage where we want to deploy the dbscripts portion of this. That means that on Thursday 17:00 until 20:00 UTC+1 we will close down repos.archlinux.org for any package updates. The idea is to try limit any potential unforseen bugs and have a small testing phase before opening it like normal. If we do find bugs we will rollback any changes and work out the bugs. If everything goes according to plan we’ll work on a devtools patch that would allow debug package updates. Then it is up to us if we enable debug for all packages or make it opt in. If people are curious about the introduced changes, they can be found here: https://gitlab.archlinux.org/archlinux/dbscripts/-/merge_requests/21 The changes have been deployed on repos.archlinux.org, everything should work as expected. If you encounter issues please report them either in this mail thread or on #archlinux-devops on libera.chat Thanks advance, Jelle van der Waa Thanks for your work, Jelle!
Re: [arch-dev-public] Library dependencies
On 2021-12-16 19:53 +1000 Allan McRae via arch-dev-public wrote: >Assuming that dependent library is not used elsewhere in the package, >and the extra library had a provide of its library version, then this >would add an extra dependency. > >There are several options: >1) disable autodeps - these really do not need used everywhere... >2) split the package >3) move the binary into /usr/lib/ and add a symlink to >/usr/bin. Then (assuming BIN_DIR=usr/bin is the usual search path), the >dependency would not be added. > >Saying that, I am against optional dependencies that are genuinely >needed for a binary to run. I think these should be used for features >that could be dynamically loaded if the optional dependency is present. > I prefer package splitting if that is not the case. I thought it was a supported use case but I agree with you that it's better to split. >> You can have multiple packages that provide the same command, but there may >> be rare cases where two conflicting packages provide unrelated commands with >> the same name, or a restricted version of a command that may not support the >> full argument set. It's worth considering how to handle such cases now before >> settling on a syntax. > >Do you have an example? I don't like adding complexity for "what if" >cases that may never occur. Nope, only a vague memory of some package conflict several years ago with two identically named commands that did completely different things. I think it was eventually solved by renaming one and telling upstream that the name was already used for a common executable. So yeah, it's not really an issue. >For the case you described, cmd:foo is provided by two packages, foo1 >and foo2. foo2 has a subset of the functionality. Then you could >depend on cmd:foo if either works, or foo1 if you need the full >functionality. Ok >> For optdeps, what I mean is if the normal dependency would be >> "lib:libgpgme.so.11", how will you parse the normal optdep syntax of >> "pkgname: reason"? "lib:libfoo.so.13: required for the command foo". Won't >> using the same delimiter in two different contexts be problematic? >> > > From memory, the space in ": " is important for >optdepends. I need to check, but I don't think the PKGBUILD linter will >let PKGBUILDs with optdepends without the space build. And pacman will >not split the string without it. So this should be fine. I wasn't sure that the space was enforced. If it is, then there's no issue. Coming back to your initial question: >Any opinions on this would be greatly appreciated. Is this a better >system than the current one? Is adding automatic dependencies against >the spirit of makepkg where everything is in the PKGBUILD? It seems better to me. Less tedious and error-prone. Regards, Xyne
