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

Bug#1016875: RFS: freefilesync/11.23-1 [ITP] -- cross-platform file sync utility, gpl release



Hi,

On Thu, Aug 11, 2022 at 03:27:14PM -0400, Boyuan Yang wrote:
> * You indicated "Multi-Arch: foreign" in debian/control file. However
> according to https://wiki.debian.org/MultiArch/Hints#ma-foreign , M-A:
> foreign only applies to Architecture: all packages. Your package is not of
> Architecture: all.

To clarify, the mentioned wiki explains how the Multi-Arch hinter comes
up with its suggestions. In this specific section how a package which
ticks all the boxes can surely be marked M-A:foreign. Packages who do
not tick (all) the boxes could be valid candidates for M-A:foreign as
well, its just that an automated process like the hinter can't decide
that in the general case.¹

I suppose this package could be marked M-A:foreign as it likely has no
architecture-specific interfaces but that needs to be checked to be
sure. I also suppose that it is not very useful to mark it as such in
any case as it looks like a GUI and those tend to be leaf packages, but
M-A only comes into play if other packages (build-)depend on your
package.

So I would recommend to refrain from setting M-A:foreign for this
package until you are either REALLY SURE its the correct thing to do
OR some other Debian contributor tells you they need you to set it.


Best regards

David Kalnischkies


¹ sed for example is M-A:foreign even though it is arch:any as the
output it produces does not change regardless of you running it on amd64
or armhf. A compiler like gcc on the other hand produces output
(= machine code) specific to the architecture it runs on and hence can
not be marked M-A:foreign (And than an interpreter like python3 comes
along and it becomes complicated. Also, this is a gross simplification).

Attachment: signature.asc
Description: PGP signature


Reply to: