[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 <andreas@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


Reply to: