Hi! On Tue, 2014-11-18 at 14:30:09 +0100, Ondřej Surý wrote: > Control: severity -1 wishlist > Control: reassign -1 dpkg
> as discussed with helmut on IRC, I am reassigning back to dpkg with > severity wishlist. No problem. > dpkg-maintscript-helper (and dpkg) know the arch of previous package, so > it could support this scenario (and the reverse one). dpkg-maintscript-helper does not have enough information for this, as dpkg only passes the architecture of the package instance currently being acted on, be that the new or the old. > Thus filling this as a wishlist... feel free to mark it as wontfix or > just document that it won't be supported never ever - both are fine with > me, but of course if you can come up with some solution that would allow > this to work without jumping through the hoops, it would be much > preferred. I'll think about this, but take into account that dpkg-maintscript-helper has always been just a hack to cover deficiencies in dpkg itself, and a proper integrated solution should be developed instead. If a solution for this does not interfere much or does not make other things ugly I might add it, otherwise I'd rather come up with a proper replacement for the helper. But, I might end up just closing it, see below… > On Tue, Nov 18, 2014, at 13:08, Ondřej Surý wrote: > > On Tue, Nov 18, 2014, at 12:24, Guillem Jover wrote: > > > On Tue, 2014-11-18 at 08:20:36 +0100, Ondřej Surý wrote: > > > > Package: dpkg > > > > Version: 1.17.21 > > > > Severity: grave > > > > File: /usr/bin/dpkg-maintscript-helper > > > > > > (BTW, if this had been an issue in dpkg, then it would not have been > > > grave, as it would not break unrelated software, just the one currently > > > being acted on.) > > > > JFTR I have discussed this with Helmut Grohne on #-devel before filling > > the bug. I only meant that this would at most be serious not grave. :) > > > dpkg-maintscript-helper only does what it is told. In this case the > > > packaging has not specified a package name (with the required > > > arch-qualifier) to the dpkg-maintscript-helper call, so it cannot > > > infer that you are doing an arch switch. Please read the man page for > > > the command for more details. > > > > The manpage doesn't say anything about upgrades from arch:any to > > arch:all, just about Multi-Arch? Hmm, true, it's all very implicit. I'm fixing the <package> argument description for 1.18.x to make all this more clear. > > > What I've not checked is if debhelper can pass different arguments > > > depending on the maintainer script invoked, which _might_ be required > > > here, but I've not thought about it. Because then you'd probably need > > > to call dpkg-maintscript-helper manually. > > > > The problem here is more complex - which arch should I pick in the call? > > > > E.g. should I pass f.e. libcyrus-imap-perl24:$(dpkg > > --print-architecture) to the dpkg-maintscript-helper call? «dpkg --print-architecture» is never the right answer when dealing with binary package architectures. After having checked the code, in this case just passing the arch-unqualified package name should be enough. > > Would that work for M-A packages? No, in that case you'd need to arch-qualify them, but you'd have the additional problem of switching from possibly multiple M-A:same instances to a single M-A:no arch:all instance, which ISTR apt does not handle too well? > > > In any case, definitely a bug in the packaging, and as such reassigning. > > > > I can definitely fix that in the packaging, but it's going to be a > > horrible hack :(. I think it's just way simpler than what it seemed, before having checked. :) Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
