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
Bug#983092: xapps-common:all is not properly arch-independent
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. I was too tired when I filled the bug to actually notice that it was a versioned library package I spoke about. Doh. Cheers, Sven Andreas Henriksson schrieb am Fr., 19. Feb. 2021, 21:22: > Hello, > > On Fri, Feb 19, 2021 at 10:45:41AM +0100, Sven Mueller wrote: > > Package: xapp > > Version: 2.0.6-1 > > Severity: serious > > > > xapps-common is tagged as architecture:all, but the generated > > xapp-sn-watcher.desktop included in it depends on the architecture it was > > built on. > [...] > > 1) Move the autostart file into the respective libxapp1 packages (with > the > > binary) > [...] > > 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, I also think it's very wrong to ship > non-SO-verioned files in a libfooN package! > (You'll most likely cause a file conflict bug when you later move > to libxapp2 in the future the entire reason we put the SO version > in the package name is to make the different versions co-installable, > but if you put non-versioned files in the package then you're breaking > that) > > The executable and desktop file should really be in a different > (possibly newly added) package! > > 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? > > Regards, > Andreas Henriksson > >
Bug#983092: xapps-common:all is not properly arch-independent
Hello, On Fri, Feb 19, 2021 at 10:45:41AM +0100, Sven Mueller wrote: > Package: xapp > Version: 2.0.6-1 > Severity: serious > > xapps-common is tagged as architecture:all, but the generated > xapp-sn-watcher.desktop included in it depends on the architecture it was > built on. [...] > 1) Move the autostart file into the respective libxapp1 packages (with the > binary) [...] 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, I also think it's very wrong to ship non-SO-verioned files in a libfooN package! (You'll most likely cause a file conflict bug when you later move to libxapp2 in the future the entire reason we put the SO version in the package name is to make the different versions co-installable, but if you put non-versioned files in the package then you're breaking that) The executable and desktop file should really be in a different (possibly newly added) package! 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? Regards, Andreas Henriksson
Bug#983092: xapps-common:all is not properly arch-independent
Package: xapp Version: 2.0.6-1 Severity: serious xapps-common is tagged as architecture:all, but the generated xapp-sn-watcher.desktop included in it depends on the architecture it was built on. By accident, we rebuilt the arch:all packages from xapp on i386, while our main architecture is amd64. The result is an xapp-sn-watcher.desktop file that isn't functional, as it leads to: systemd-xdg-autostart-generator[29117]: Exec binary '/usr/lib/i386-linux-gnu/xapps/sn-watcher/xapp-sn-watcher' does not exist: No such file or directory Similarly, if someone would install Debian bullseye with a main architecture i386 (not many would do, but there are certainly some) or an ARM architecture, this would also fail (because there, it refers to the x86_64 library directory). Thus I'm setting the severity to Serious here - It is broken for any architecture other than amd64 in Debian. There are probably two possible fixes (maybe more): 1) Move the autostart file into the respective libxapp1 packages (with the binary) 2) Use the alternatives mechanism to let one binary package provide the executable at a common location. Cheers, Sven
