[feature request] SystemPackageTool platform support

[uilianries]

To help us debug your issue please explain:

As supported by MSBuild, I would like to add the same platforms parameter for SystemPackageTool, where it will solve the package platform to be installed.

def system_requirements(self):
        if tools.os_info.with_apt:
            packages = [
                "libgtk-3-dev",
                "libatk1.0-dev",
                "libglib2.0-dev",
                "libpango1.0-dev",
                "libgdk-pixbuf2.0-dev",
                "libcairo2-dev",
                "libpango1.0-dev",
                "libcairo2-dev"
            ]
            if tools.cross_building(self.settings):
                target_arch = {"x86": "i386", "armv7": "arm", "armv7hf": "armhf"}
                conan_arch = str(self.settings.arch)
                packages = ["%s:%s" % (package, target_arch[conan_arch]) for package in packages]
            installer = SystemPackageTool()
            installer.install(" ".join(packages))

As you can see, I need to append the package name to solve the target platform. I think it could be solve automatically:

def system_requirements(self):
        if tools.os_info.with_apt:
            packages = [
                "libgtk-3-dev",
                "libatk1.0-dev",
                "libglib2.0-dev",
                "libpango1.0-dev",
                "libgdk-pixbuf2.0-dev",
                "libcairo2-dev",
                "libpango1.0-dev",
                "libcairo2-dev"
            ]
            distro_archs = None
            if tools.cross_building(self.settings):
                distro_archs = {"x86": "i386", "armv7": "arm", "armv7hf": "armhf"}
            installer = SystemPackageTool()
            installer.install(" ".join(packages), platforms=distro_archs)

Regards!

• I've read the CONTRIBUTING guide.
• I've specified the Conan version, operating system version and any tool that can be relevant.
• I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

[jgsogo]

You would need to pass to the installer.install:

• the target platform, or
• the distro_archs dictionary and the arch, right?

Or, does it make sense to have the distro_archs inside the SystemPackageTool and pass only the arch? Of course, that distro_archs should be an optional argument to override it.

Does it work for all the system packager tools (appending the arch to the package name like package:arch)? Does it work for all the versions?

...you know that system packages are something we don't feel comfortable with, that's the only reason for so many questions 😸

[uilianries]

I know, SystemPackageTools is evil, but is what we have for now ...

does it make sense to have the distro_archs inside the SystemPackageTool and pass only the arch?

I think yes, since is the same pattern for all packages that we have used with SystemPackageTools.

Of course, that distro_archs should be an optional argument to override it.

Right! If not specified, the behavior should be the same as now.

Does it work for all the system packager tools (appending the arch to the package name like package:arch)?

No ... APT uses the suffix :, YUM uses ., pacman uses the prefix lib-. No idea about Chocolatey

Does it work for all the versions?

Yes, they are compatible.

I think your question Does it work for all the system packager tools make me think again.

We can implement this feature, but we will need to check which package manager we are using. This is not different from what we have done for our packages, most of the time we just copy that pattern from one recipe to another.

[jgsogo]

So the SystemPackageTool wrapper should select the arch and then delegate on each one (apt, yum, pacman,...) the composition of the full name for the package (suffix with :, ., prefix lib-,...). Given this neccessity, it makes sense to build the name inside, as we cannot know from the outside which one will be the package manager we are using (ok, we have the OSInfo.with/is_XXX functions but it is an implementation detail).

Probably the cleanest implementation would be to pass the settings object to the SystemPackageTools and implement all the behavior inside (even the cross compiling detection), from outside we should be able to provide the dictionary arch->platform for those cases where the hardcoded one is not valid.

[uilianries]

Probably the cleanest implementation would be to pass the settings object to the SystemPackageTools and implement all the behavior inside

Yes, it sounds better, since we can detect cross-building situation.

from outside we should be able to provide the dictionary arch->platform for those cases where the hardcoded one is not valid.

Right, as we have done for MSBuild helper.

Do you think this feature makes sense?