Re: Need help testing pacman 6.0.2 debug packages

[Morten Linderud]

Just to followup on this abit.

6.0.2-1 was released, but we found a bug as the $pkgbase was not properly added
to the /usr/src/debug/ portion of the string.

We patched[1] this bug with 6.0.2-2 but it broke several debug packages, but it
turns out this actually breaks packages built in sub-directories as we are
ignoring some files.

λ ~ » gdb /usr/bin/pacman
[...]
(gdb) list
Downloading 0.04 MB source file 
/usr/src/debug/pacman-6.0.1/pacman-6.0.1/build/../src/pacman/pacman.c
1073char *cl_text = arg_to_string(argc, argv);
1074if(cl_text) {
1075alpm_logaction(config->handle, 
PACMAN_CALLER_PREFIX,
1076"Running '%s'\n", cl_text);
1077free(cl_text);
1078}
1079}
1080
1081/** Main function.
1082 * @param argc
(gdb) info source
Current source file is ../src/pacman/pacman.c
Compilation directory is /usr/src/debug/pacman-6.0.1/pacman-6.0.1/build

In gdb we have this weird relative path going on:
/usr/src/debug/pacman-6.0.1/pacman-6.0.1/build/../src/pacman/pacman.c

Is in theory this absolute path
/usr/src/debug/pacman-6.0.1/pacman-6.0.1/src/pacman/pacman.c

But gdb explicitly checks for /usr/src/debug/pacman-6.0.1/build existing in the
package, which means we need to retain the empty `/build` directory when we make
the debug packages. Previous iterations of pacman just omits this, and other
distributions has pre-defined build directories which works around this issue a
bit.

This issue is semi-unique to build systems where we are building in
sub-directories (like meson), so things like Go and Rust is going to *probably*
work without us patching this.

This has been patched (properly this time) with some help from Allan, now we
just create all the directories we see, empty or not, and it should hopefully
work out :)

I have yet to release a new package into testing as I have been travelling. But
fetching 6.0.2-2 from the archive to test different ecosystem should still
mostly work I think.

[1]: 
https://gitlab.archlinux.org/pacman/pacman/-/commit/478af273dfe24ded197ec54ae977ddc3719d74a0

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [core] cleanup

[David Runge]

On 2022-10-12 11:29:52 (+1000), Allan McRae wrote:
> On 11/10/22 21:00, Levente Polyak wrote:
> > On 10/11/22 12:05, David Runge wrote:
> > > - preserve base-devel as a group there
> > 
> > makedepends doesn't actually matter, similar how checkdepends doesn't
> > matter. Our builders always have the full repository set available
> > (minus multilib). We only need to consider runtime depends.
> 
> I would argue that makedepends and checkdepends do matter from a testing
> perspective.   If we have [core] defined at essential packages to bootstrap
> a system, build time dependencies remain important and should go through
> testing.
> 
> Of course that depends on our definition of [core]...  I like the above
> definition, as it reflects the history of our distro starting from Linux
> From Scratch, and the build dependencies for things in [core] are fairly
> fundamental to things outside core too (e.g. meson) and deserve enforced
> [testing].
> 
> It also serves us well as more architectures happen - that would make [core]
> a self contained start point for bootstrapping an architecture.

If we look at it from a bootstrap perspective, then it would indeed be
good to become self-contained in regards to makedepends and maybe also
checkdepends (more overhead though).

I agree, that this should encompass build tools used for the packages in
core (such as meson) in the future in regards to "going through
testing", but I would not want all the build tools in there (e.g. cmake,
waf, scons, whathaveyou), if they are not required by packages in
[core]. This breaks with the above base-devel assumption in case we ever
want to add all the build tools to it.

However adding build tools in general also drags in its own kitchen
sink, and I understand why the rather small group of developers might
not be fond of this.

> In summary, we need to define what it is we are trying to achieve with
> [core].

Hm, we could create an RFC for evaluating and defining this better.
It seems, that people have very different ideas and opinions about what
should be in core and what not :)
Maybe this would also provide a better overview to what proposed changes
would actually mean in terms of added packages etc.

Best,
David

-- 
https://sleepmap.de


signature.asc
Description: PGP signature