On Tue, Feb 02, 2021 at 11:47:41PM +0100, Lorenzo wrote: > thanks for the patch. I guess that it is because this package use only > perl ans shell, am I correct?
Not exactly. Multi-Arch is an assertion of how your package behaves rather than an assertion about how it is implemented. You can quite easily produce architecture-dependent behaviour using perl and shell. Similarly, you can behave the same on all architectures in a C executable (e.g. false/sleep/tar/test/true/...). The question "Can my package be Multi-Arch: foreign?" can be roughly translated to "Can a user tell apart what architecture is being used by interacting with the package using reasonable interfaces?" This is a little more difficult for Architecture: all packages as they are mapped to the "native" architecture. So you cannot merely replace the package, but need to replace the base system instead. Simple examples: If you run "gcc test.c", the resulting test.o quite strongly depends on where you run the compiler. If you create a tar archive using tar, it'll be difficult to tell the processor architecture from the resulting archive. Corner case: GNU make supports using -lfoo flags as dependencies and looks them up on an architecture-specific search path. The vast majority of users of make use it in an architecture-independent way, but some do not. For that reason it was later changed to M-A:allowed from early M-A:foreign. > However i plan further development on this package, so I'd like to > understand if and how this patch will limit my options: for example, if > i call (from perl or sh) some external executable that is arch > specific then I'll need to remove the multi-arch: foreign? Or, as long > as I stick with something that does not need to go through a compiler, > like sh perl or python, it's always safe to mark Multi-Arch ? Further development seems like a good idea. The package uses useradd instead of the policy-recommended adduser. Is there a good reason for doing so? The approach taken here entirely sidesteps the established and declarative sysusers.d format. Is there a reason for not cooperating with it? Niels Thykier is working a lot on removing maintainer scripts and turning them into declarative alternatives such as triggers. dh-sysusers works towards the opposite. Why? As far as I can tell, project consensus is that system users should not be removed on purge, but dh-sysuser does so. From my subjectively skewed perception, dh-sysuser has only created problems, not solved any. I acknowledge that this is not the whole picture. Even though changing the multiarch value later is certainly possible, I don't think it'll be needed nor reasonable. The task of dh-sysuser is implementable in an architecture-independent way as the interface it is meant to provide is architecture-independent. Later removing a Multi-Arch: foreign would make a ton of packages uninstallable and all of the above packages cross-bd-uninstallable. So practically, you'll have to stick with it or risk patches removing dh-sysuser usage from the archive. Helmut
