Bug#983092: xapps-common:all is not properly arch-independent
Hi all,
thanks Sven for the report - good catch - and thanks to Fabio for the quick
fix. I have uploaded the package with Fabio's fix to unstable just now.
Here my comments:
On Fri, 19 Feb 2021, Sven Mueller wrote:
> 1) Move the autostart file into the respective libxapp1 packages (with the
> binary)
On Fri, 19 Feb 2021, Andreas Henriksson wrote:
> Seems like Fabio Fantoni went with this solution and while I agree
> that desktop files should be shipped in the same package as the binary
> they launch in general,
Let us separate the issues first:
* first of all, the fix by Fabio does indeed fix the bug, so that
is a correct fix.
* While I agree that it is nice to have .desktop files and their
programs in the same package, it is not an obligation (last time I
checked the policy), and I have several other cases where it is not
the like this.
So while it would be nice - we can target it after bullseye release.
On Fri, 19 Feb 2021, Andreas Henriksson wrote:
> I also think it's very wrong to ship
> non-SO-verioned files in a libfooN package!
On Sat, 20 Feb 2021, Sven Mueller wrote:
> I agree, Andreas. I would actually consider the binary being in the ABI
> versions library package questionable, now that I think about it. You
> wouldn't be able to run two versions of this at the same time anyhow.
Again, I agree, but consider it irrelevant for bullseye.
Please open a bug with severity important, and we will work on this
after the release of bullseye. There is no libxapp2, and much more there
will not be one in bullseye, so this is theoretical hair splitting that
is only for the "beauty" but has not influence on user experience.
On Sat, 20 Feb 2021, Sven Mueller wrote:
> Given we're in freeze it might be too late to introduce a new binary
> package (if that's needed), but fixing one bug by doing something
> wrong doesn't feel like debian style either. Wouldn't it be better
> to just ask the release team which solution they prefer and possibly
> get an exception for introducing a new binary package if needed?
No. First of all, as I mentioned, having desktop and the invoked program
in different package is not a requirement. At least **I** will not
introduce a new binary package and try to fix all corner cases so late,
just for some beauty.
****
To sum it up:
- please submit a bug of severity important concerning the SO version
file
- please submit a bug concerning the fact that desktop file and invoked
program are in different packages - severity normal
- after release of bullseye we will clear this up
Thanks
Norbert
--
PREINING Norbert https://www.preining.info
Fujitsu Research Labs + IFMGA Guide + TU Wien + TeX Live + Debian Dev
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Reply to: