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 <andr...@fatal.se> 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 > >
