[arch-dev-public] Debug package support in dbscripts
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 OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] Library dependencies
On 2021-12-13 18:35 +1000
Allan McRae via arch-dev-public wrote:
>Hi all,
>
>I submitted a patchset to pacman that I would like some packager
>feed-back on. [1]
>
>Essentially this replaces the old libdepends/libprovides system into
>something akin to that used by APK. In short, makepkg.conf will have
>a variable like:
>
>LIB_DIRS=('lib:usr/lib' 'lib32:usr/lib32')
>
>At the end of package building, makepkg will look in the library
>directories and add a provide. E.g. for pacman:
>
>provide = lib:libalpm.so.13
>
>Note the prefix matches the prefix given to the relevant directory in
>LIB_DIRS. Similarly, makepkg can add dependencies on libraries. E.g.
>pacman may have:
>
>depends = lib:libgpgme.so.11
>
>Note, to help with bootstrapping this system, or if packages just do
>not want to add libprovides, the depends entries are only added if a
>package actually provides them.
>
>This is different to the APK system for libraries which uses "so" as the
>prefix and is not configurable. But Alpine used musl, which has no
>concept of multilib, so we need to be a bit more flexible. Note the
>"lib" and "lib32" prefixes are just for discussion. Arch can configure
>how they want.
>
>The dependency/provides additions can all be disabled in pacman.conf
>with the '!autodeps' option.
>
>Note that APK has similar things for binaries and pkg-config files. e.g.
>provides = cmd:pacman
>provides = pc:libalpm
>
>These can now be readily be added as dropins to libmakepkg.
>
>
>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?
>
>Thanks,
>Allan
>
>[1] https://gitlab.archlinux.org/pacman/pacman/-/commits/allan/autodeps
Is it necessary to hard-code LIB_DIRS with prefixes in each PKGBUILD that
provides them? It seems simpler to me to use the standard library paths for the
system with optional overrides in makepkg.conf. Makepkg could then scan those
directories in the pkgdir, check the architecture of any shared objects and
automatically add the prefixed provides (with the prefixes also configurable in
makepkg.conf).
Basically, any shared objects installed to system paths are effectively provided
by the package anyway so they may as well all be included in the array so that
packages can explicitly depend on them as packagers please. Any shared objects
installed elsewhere are effectively invisible except for packages that
specifically look for them in non-standard locations, but then it makes more
sense to have a direct dependency on the package itself, with a version
specification if necessary.
On the depends side, the shared objects used by the package can also be scanned
but it's obviously not as straight-forward to determine whether dependencies
are general, versioned or even optional. A tool could be used to generate a
list or prompt the package interactively to select relevant so deps to add to
the package. Guidelines could be provided by the tool itself to avoid
overspecification. It would be a shame if this led to a permanent dependency
hell of packages depending explicitly on old versions even when not necessary.
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.
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).
Re: [arch-dev-public] Library dependencies
On 15/12/21 14:11, Xyne via arch-dev-public wrote:
On 2021-12-13 18:35 +1000
Allan McRae via arch-dev-public wrote:
Hi all,
I submitted a patchset to pacman that I would like some packager
feed-back on. [1]
Essentially this replaces the old libdepends/libprovides system into
something akin to that used by APK. In short, makepkg.conf will have
a variable like:
LIB_DIRS=('lib:usr/lib' 'lib32:usr/lib32')
At the end of package building, makepkg will look in the library
directories and add a provide. E.g. for pacman:
provide = lib:libalpm.so.13
Note the prefix matches the prefix given to the relevant directory in
LIB_DIRS. Similarly, makepkg can add dependencies on libraries. E.g.
pacman may have:
depends = lib:libgpgme.so.11
Note, to help with bootstrapping this system, or if packages just do
not want to add libprovides, the depends entries are only added if a
package actually provides them.
This is different to the APK system for libraries which uses "so" as the
prefix and is not configurable. But Alpine used musl, which has no
concept of multilib, so we need to be a bit more flexible. Note the
"lib" and "lib32" prefixes are just for discussion. Arch can configure
how they want.
The dependency/provides additions can all be disabled in pacman.conf
with the '!autodeps' option.
Note that APK has similar things for binaries and pkg-config files. e.g.
provides = cmd:pacman
provides = pc:libalpm
These can now be readily be added as dropins to libmakepkg.
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?
Thanks,
Allan
[1] https://gitlab.archlinux.org/pacman/pacman/-/commits/allan/autodeps
Is it necessary to hard-code LIB_DIRS with prefixes in each PKGBUILD that
provides them? It seems simpler to me to use the standard library paths for the
system with optional overrides in makepkg.conf. Makepkg could then scan those
directories in the pkgdir, check the architecture of any shared objects and
automatically add the prefixed provides (with the prefixes also configurable in
makepkg.conf).
LIB_DIRS is specified in makepkg.conf, not in PKGBUILDs. Given
usr/lib/ is not even standard for 64bit libraries, I do not want to hard
code anything.
Basically, any shared objects installed to system paths are effectively provided
by the package anyway so they may as well all be included in the array so that
packages can explicitly depend on them as packagers please. Any shared objects
installed elsewhere are effectively invisible except for packages that
specifically look for them in non-standard locations, but then it makes more
sense to have a direct dependency on the package itself, with a version
specification if necessary.
Non-standard paths for libraries was mentioned on pacman-dev. For
these, LIB_DIRS can be added to in the PKGBUILD.
On the depends side, the shared objects used by the package can also be scanned
but it's obviously not as straight-forward to determine whether dependencies
are general, versioned or even optional. A tool could be used to generate a
list or prompt the package interactively to select relevant so deps to add to
the package. Guidelines could be provided by the tool itself to avoid
overspecification. It would be a shame if this led to a permanent dependency
hell of packages depending explicitly on old versions even when not necessary.
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.
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.
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).
People can manually add such things as op
