Re: Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency
On Mon, Oct 10, 2022 at 08:50:49AM +0800, Paul Wise wrote: > On Sun, 2022-10-09 at 18:54 +0200, David Kalnischkies wrote: > > I suppose we could use 'foo-dbgsym Enhances foo:arch (= version)'. > > That sounds interesting and would be nice generally, however... > > > On a sidenote: What the Depends ensures which the Enhances doesn't is > > that they are upgraded in lockstep. As in, if for some reason foo (or > > foo-dbgsym) have their version appear at different points in the archive > > apt would hold back on a Depends while with Enhances this dependency > > would be broken and hence auto-remove kicks in. > > For the rolling Debian suites, the main and dbgsym archives are often > out of sync, the dbgsym packages updates sometimes appear first and > sometimes second. Keeping foo/foo-dbgsym in sync is strongly needed Oh, are they? I thought they would be better in sync. Never noticed, but I tend to have extremely luck avoiding any kind of apt problem… Anyway, that is solvable. An 'upgrade' e.g. keeps back an upgrade if that would break a Recommends. Seems reasonable to keep it back also if it would break a previously satisfied Enhances as loosing the features of a plugin due to an automatic upgrade seems super-bad. For full-upgrade we could go with a rule specifically targeted at packages from the 'debug' section with such Enhances dependencies. If you have multiple architectures of an M-A:same package installed they keep each other in check as well as long as the "old" version is still downloadable. So that shouldn't be too hard™… The downside is that both are heuristics which are solver dependent, as such aptitude likely and external solvers surely won't support that (without implementing similar solution optimisation logic). That said, this isn't really different from "miss-using" Depends for it to have it be hold-back as is not working with every solver in every situation either. For apt I am actually somewhat surprised if it does in the general case as the -dbgsym should have close to no power (as nothing depends on it), while the thing it has debug symbols for probably has things depending on it, so if it comes to upgrading foo or keeping it back it should favour upgrading foo (and hence removing foo-dbgsym) in most cases currently (full-upgrade that is, upgrade of course not). Anyway, if that is an acceptable/desirable option we should probably move any apt machinery discussion into its own bugreport and away from d-d@ and debhelper. For this thread I would say its enough to decide if using Enhances in this way is acceptable for everyone. If and how apt (and/or other tools) make then use of the data is up to them in the end. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#903158: Info received (Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency)
Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debhelper Maintainers If you wish to submit further information on this problem, please send it to 903...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 903158: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903158 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency
On Sun, 2022-10-09 at 18:54 +0200, David Kalnischkies wrote: > I suppose we could use 'foo-dbgsym Enhances foo:arch (= version)'. That sounds interesting and would be nice generally, however... > On a sidenote: What the Depends ensures which the Enhances doesn't is > that they are upgraded in lockstep. As in, if for some reason foo (or > foo-dbgsym) have their version appear at different points in the archive > apt would hold back on a Depends while with Enhances this dependency > would be broken and hence auto-remove kicks in. For the rolling Debian suites, the main and dbgsym archives are often out of sync, the dbgsym packages updates sometimes appear first and sometimes second. Keeping foo/foo-dbgsym in sync is strongly needed since old or new dbgsym has zero value for debugging and just because the archives are currently not in sync, that doesn't mean one wants out of sync dbgsyms to be removed. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency
On Sat, Oct 08, 2022 at 03:42:59PM +0100, Simon McVittie wrote: > I was under the impression that the Debian archive does not allow > dependencies with an explicit architecture like this, only the :any > qualifier for M-A: allowed packages (like python3:any). "allow" is a strong word especially if you don't find it in policy (but then, policy documents existing usage, so some usage pre-dates policy by definition I guess). It is also not really related to MultiArch ipso facto as the initial spec explicitly mentions it as a dropped discussion point. [0] It was later added with MultiArchCross [1] with the previously mentioned caveats still in place as cross-building is not a thing in the archive (as we build everything natively – ignoring special cases like win32). That said, we have some packages declare cross-architecture dependencies in the archive (even in stable), but not as a hard-dependency as indeed various archive tools can not deal with such dependencies and its unclear if they even should as MultiArch is not a default configuration. (which I want to highlight explicitly here as it is frequently compared to things we ship or enable by default for everyone) Examples are: - crossbuild-essential-i386 depends on gcc-i686-linux-gnu | gcc:i386 - gamemode recommends libgamemode0:i386 - libc6-i386 conflicts with libc6-x32:i386 (and that is just looking at :i386 in amd64 as that is a somewhat common usage to bring in i386 packages on amd64.) The trick previously was to depend on a package only available in the other architecture, which equally doesn't work with tools who only have a single arch available and is less obvious for the casual on-looker. apt (and libapt-based friends) and dpkg agree mostly on what things mean and if they don't it tends to be way beyond the pay grade of the average DD (an example would be #770345 that is have left hanging for 8 years now) – no disrespect intended! It is just that I would certainly not want to reason about any of that stuff if that wouldn't come hand in hand with being an apt dev… bringing all those nitty-gritty details to policy would certainly be an interesting endeavour but if it would really be a service to human kind^W^Wcontributors I am not so sure even if its frequently used as an argument against MultiArch and related projects. Best regards David Kalnischkies [0] https://wiki.ubuntu.com/MultiarchSpec#Allow_official_packages_to_have_cross-architecture_deps [1] https://wiki.ubuntu.com/MultiarchCross#Cross-architecture_dependencies signature.asc Description: PGP signature
Re: Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency
On Sun, Oct 09, 2022 at 10:26:39AM +0800, Paul Wise wrote: > I have often wanted a different kind of relationship between packages > and their dbgsym packages than mere Depends. Currently when a dbgsym is > installed it keeps the library package installed even after it is no > longer used and both should be auto-removed. I suppose we could use 'foo-dbgsym Enhances foo:arch (= version)'. Okay, foo-dbgsym doesn't enhance the functionality of foo directly, but declaring it "enhances default-core-viewer | gdb" is not really a useful remark and surely, like with a "normal" plugin, its usefulness shrinks to fringe use cases without foo being present (at least in the form of a core file produced by it). apt currently doesn't handle Enhances in terms of auto-removal, but I would be willing to change it so that: foo is manually installed: all things enhancing it are not auto-removed. foo is auto-installed: considered for auto-removal if all things enhancing it are also auto-removable (or in other words: foo-dbgsym is manually installed: all things enhanced by it are not auto-removed). That should give you the property that if nothing depends on foo anymore and you don't have anything enhancing it manually installed, it will be auto-removed, while foo and its enhancing foo-dbgsym (or plugin or whatever) stay around as long as foo is still in use – which allows you to set foo-dbgsym to auto-installed after you have it (manually) installed, while e.g. Helmut can install foo-dbgsym without installing a (for him) useless foo keeping it on manual and hence having it stick around. Looking at existing Enhances I can imagine this doing the right thing™ also for more normal plugins and other enhancers: If you want to use emacs mode you have to install a mode – emacs is brought in via a Recommends if its not already there. You can't express that you installed that mode for emacs only. You have to keep it manually installed or otherwise current apt autoremoves it. It also keeps emacs installed even if you later decide its not your thing and apt could autoremove it. With the change above you could set the mode to auto-installed and have apt do its thing after emacs is [auto]removed. Similar, if you install abook to use it from inside mutt, you have to keep it manually installed – which perhaps you want as that is how you manage your adressbock and want to keep it even if mutt is gone, but you can't express the opposite: That you have no need for abook if mutt (or any other thing it might enhance) isn't around anymore. Enhance is mainly used by software centers currently to show plugins and stuff so you can explicitly install it – as in, they will all end up being manually installed. Software centers usually hide things of no interest to casual users, so I am reasonably sure dbgsyms are already hidden (otherwise they would already appear in searches and such). That means that potentially less things are considered for autoremoval with the above change: In the emacs case (and many others) the enhanced foo is not considered for auto-removal due to an existing and already interpreted Depends/Recommends/Suggests, so no change. In the (less common) case¹ of installing abook on its own and having mutt brought in via an unrelated unused dependency chain it would now keep mutt installed as long as abook is considered manually installed. Also, the reverse is true. Keeping "too many" things installed is already a problem as we have no idea if a Recommends/Suggests is really used for anything or if it was brought in for completely unrelated reasons and is now unused (or if it was brought in for unrelated reasons, but the user discovered and heavily uses it via the other tool recommending it). We err on removing "too few" in all those cases as that is usually a much smaller problem in practice, so that doesn't feel like too big of a difference. I left it intentionally open if and who does set foo-dbgsym to auto-installed after it is installed. 'apt install foo-dbgsym' gives you a manually installed foo-dbgsym and you would need to 'apt-mark auto' it afterwards. I think aptitude can do that in one go. I would probably add a way in apt as well (a NeverManual similar to NeverAuto perhaps), but certainly not by default (imagine the emacs example from above, if the enhancer would be set to auto-installed by default and emacs wasn't installed before they would both considered garbage upon install…). On a sidenote: What the Depends ensures which the Enhances doesn't is that they are upgraded in lockstep. As in, if for some reason foo (or foo-dbgsym) have their version appear at different points in the archive apt would hold back on a Depends while with Enhances this dependency would be broken and hence auto-remove kicks in. That might actually be a benefit through as if you remove the debug section from your sources a hold back is not really a good idea. It seldomly is a good idea for various reasons (hence why apt likes to go
Re: Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency
On Sat, 2022-10-08 at 11:00 +0200, Niels Thykier wrote: > 2) We now have a debuginfod service, so you do not even have to install > dbgsym packages anymore (if you configure gdb to use it). For the > cases where you do install the dbgsym, you still have to manage > inter-source dbgsym dependencies manually. The debuginfod service is not protected by the archive keys and it isn't available offline, so I currently prefer to use debian-goodies' `find-dbgsym-packages --install` command. Since I don't have any foreign architectures enabled, I can't be affected by the issue with not strict enough dependencies though. Removing all dependencies would mean that removing an obsolete library package would no longer also remove the dbgsym package and a lot of obsolete library packages would accumulate without manual action and it could be time consuming to track down no longer used dbgsym packages. Keeping the dependencies does also block some use-cases, some of that can be worked around using debuginfod, with the usual downsides. I have often wanted a different kind of relationship between packages and their dbgsym packages than mere Depends. Currently when a dbgsym is installed it keeps the library package installed even after it is no longer used and both should be auto-removed. So I believe the optimal thing to do would be stricter depends for now and later if apt adds some kind of special handling for dbgsym, then all of the Depends could be dropped to enable more use-cases. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency
Simon McVittie:
On Sat, 08 Oct 2022 at 11:00:30 +0200, Niels Thykier wrote:
On Sat, 7 Jul 2018 11:40:54 +0300 "Yuriy M. Kaminskiy"
wrote:
I think (at least, 'Multi-arch: foreign' *and* 'Architecture' != all)
packages should have explicit parent package arch dependency
Depend: foo:${Arch} (=${binary:Version})
instead of
Depend: foo (=${binary:Version})
So as a concrete example, for sed:amd64 (which is Multi-Arch: foreign),
sed-dbgsym:amd64 currently depends on sed (= 4.8-1) which can be satisfied
by sed:i386, and the request is for it to explicitly depend on
sed:amd64 (= 4.8-1) instead?
In essence, yes.
Though, I think it is better to read OP's email as a "functional
requirement" rather than the exact way to implement it.
I was under the impression that the Debian archive does not allow
dependencies with an explicit architecture like this, only the :any
qualifier for M-A: allowed packages (like python3:any). Am I basing this
on outdated information?
Policy §7 doesn't currently document multiarch qualifiers at all.
deb-control(5) documents foo:any and foo:amd64.
smcv
It is not clear to me that the archive supports it (or that apt, dak and
dpkg are all aligned on what "foo:amd64" means). However, as noted in
my debian-devel mail, I am not willing to spend time figuring out
whether "foo:amd64" works and much less provide patches if it does not.
Accordingly, I am not planning to do any research in that area.
Thanks,
~Niels
Re: Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency
On Sat, 08 Oct 2022 at 11:00:30 +0200, Niels Thykier wrote:
> > > On Sat, 7 Jul 2018 11:40:54 +0300 "Yuriy M. Kaminskiy"
> > > wrote:
> > > > I think (at least, 'Multi-arch: foreign' *and* 'Architecture' != all)
> > > > packages should have explicit parent package arch dependency
> > > >Depend: foo:${Arch} (=${binary:Version})
> > > > instead of
> > > >Depend: foo (=${binary:Version})
So as a concrete example, for sed:amd64 (which is Multi-Arch: foreign),
sed-dbgsym:amd64 currently depends on sed (= 4.8-1) which can be satisfied
by sed:i386, and the request is for it to explicitly depend on
sed:amd64 (= 4.8-1) instead?
I was under the impression that the Debian archive does not allow
dependencies with an explicit architecture like this, only the :any
qualifier for M-A: allowed packages (like python3:any). Am I basing this
on outdated information?
Policy §7 doesn't currently document multiarch qualifiers at all.
deb-control(5) documents foo:any and foo:amd64.
smcv
Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency
Hi,
I have BCC'ed debian-devel on this email to ask for input on this bug
(#903158) and ask parties that are interested to follow up there. I am
considering to remove the dependencies for -dbgsym packages on the
grounds that:
1) They are too weak when M-A: foreign is involved and they are not
always help (see the partial email quote from the bug below)
2) We now have a debuginfod service, so you do not even have to install
dbgsym packages anymore (if you configure gdb to use it). For the
cases where you do install the dbgsym, you still have to manage
inter-source dbgsym dependencies manually.
As a debhelper maintainer, I willing to either keep the status quo and
close the bug as wontfix or close the bug by removing the dependencies.
If you hoping for another outcome, I expect you to be ready to put the
effort and patches required to reach the outcome.
Thanks,
~Niels
On Sat, 4 Aug 2018 21:04:59 +0200 Helmut Grohne wrote:
Hi Niels,
On Sat, Aug 04, 2018 at 08:38:00AM +, Niels Thykier wrote:
> On Sat, 7 Jul 2018 11:40:54 +0300 "Yuriy M. Kaminskiy"
> wrote:
> > I think (at least, 'Multi-arch: foreign' *and* 'Architecture' != all)
> > packages should have explicit parent package arch dependency
> >Depend: foo:${Arch} (=${binary:Version})
> > instead of
> >Depend: foo (=${binary:Version})
> > Untested patch against debhelper 11.3.5 attached (please review
> > carefully, I'm neither M-A nor debhelper expert).
Yes, this makes somewhat sense.
Personally, I disagree with the Depends though. I've often been in the
situation of wanting to debug a foreign core file or remotely attaching
to a process on a different system. These dependencies were not helpful
at all in these situations. Personally, I'm in favour of making -dbgsym
packages dependency-less. I acknowledge that others see things
different.
In any case, we agree that if we want the dependency, then it is
presently too weak.
[...]
