Processed: Re: Bug#1038121: tracker.debian.org: debian/patches check vs. single-debian-patch in debian/source/local-options

2023-06-16 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> reassign 1038121 dpkg-dev
Bug #1038121 [tracker.debian.org] tracker.debian.org: debian/patches check vs. 
single-debian-patch in debian/source/local-options
Bug reassigned from package 'tracker.debian.org' to 'dpkg-dev'.
Ignoring request to alter found versions of bug #1038121 to the same values 
previously set
Ignoring request to alter fixed versions of bug #1038121 to the same values 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1038121: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038121
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#825385: Bug#1020533: dpkg should use /var/lib/dpkg/arch to determine native arch when running chrootless

2023-06-16 Thread Johannes Schauer Marin Rodrigues
Hi Guillem,

Quoting Guillem Jover (2022-10-10 12:23:58)
> On Thu, 2022-09-22 at 22:13:34 +0200, Johannes Schauer Marin Rodrigues wrote:
> As mentioned on IRC, the problem here (and on #825385) is indeed that dpkg
> considers its own arch the native one, and when operating on a cross-arch
> chroot, that goes wrong, both in dependency resolution and when outputting
> arch-qualified package names for example.
> 
> Fixing this properly is tricky though, because there are multiple
> requirements in tension here:
> 
>   * The external dpkg should be able to tell what's the arch for the
> internal one w/o having to execute anything (that it might not be
> able to run anyway).
>   * Setting a file on the database means either requiring a dpkg
> maintscript (for the bootstrap phase) which we are trying to get
> rid of, or offloading this to the bootstrappers (even worse), it
> also means it could be modified w/o dpkg noticing, which can break
> dependency resolution from an existing system.
>   * Shipping a file with the arch would seem like the best option (as
> that is checksummed) and not in the db, but that means then, that
> pathname under /usr needs to be selectable too at run-time, as
> that encodes configure-time vendor-specific fsys layout.
>   * Setting that directory from the config file is currently
> problematic as dpkg does not have a way to specify a different
> config directory.
>   * Perhaps just adding a new --foodir option to dpkg could be enough
> for now, if the inner dpkg uses a different pathname, in the
> same way if it uses a different database pathname.
>   * But then only specifying the db pathname would no longer be
> enough, and dependency resolution and arch-qualifying would still
> be wrong. :/
>   * But then if the file does not exist (or cannot be found in the
> «right» place) it could still fallback to the currently running
> native arch, but that looks flaky (not worse than now, though,
> but not ideal). :/
> 
> I guess I can prototype something with the --foodir idea though, but that's
> still rather meh.

once you have a prototype (even if it's not release-ready) feel free to share
it, because our CI setup is able to apply patches to source packages. So if you
have something that we can test, just send it over and we'll build a patched
dpkg to run this with our scripts.

Thanks!

cheers, josch

signature.asc
Description: signature