Open jiasli opened 2 years ago
@glaubitz, as we are continuously seeing issues with the pre-installed azure-cli
, do you think if it is possible to remove it from SUSE images? This way, our customers can always get the latest version distributed officially by Microsoft.
@jiasli No, this is not possible as we must provide our own distribution of the Azure packages as we cannot provide support to customers which install the packages from upstream.
Customers are advised to report issues with the Azure packages in openSUSE/SUSE with SUSE's Bugzilla database.
If you have customers reporting SUSE-specific issues here, please close the bug report as invalid and refer them to our bug database.
FWIW, it looks like the comment from the other bug report you are referring to talks about installing packages from Microsoft's own RPM repositories.
So, the bug here is that Microsoft's own RPM packages are missing the necessary Conflicts
field in their RPM spec file so that installation of Microsoft's own RPM packages will cause the package manager to remove SUSE's Azure packages from the system.
Also, according to the naming scheme of Microsoft's own azure-cli
packages, these packages are built for RHEL7 ("el7") [1], so I'm not sure why Microsoft recommends installing these packages on openSUSE/SLE in the first place.
Thanks @glaubitz, we really appreciate your contribution to make Azure CLI available on openSUSE.
Customers are advised to report issues with the Azure packages in openSUSE/SUSE with SUSE's Bugzilla database.
Do you mind letting us know the official link or instruction for reporting Azure CLI issues to SUSE's Bugzilla database?
So, the bug here is that Microsoft's own RPM packages are missing the necessary
Conflicts
field in their RPM spec file so that installation of Microsoft's own RPM packages will cause the package manager to remove SUSE's Azure packages from the system.
Could you provide more information on how we could leverage the Conflicts
field? Actually, azure-cli
and azure*
packages are released at very rapid pace. We can't exhaust all possible combinations and figure out which combination is compatible or not.
Also, according to the naming scheme of Microsoft's own
azure-cli
packages, these packages are built for RHEL7 ("el7") [1], so I'm not sure why Microsoft recommends installing these packages on openSUSE/SLE in the first place.
This is simply because the RPM packages works universally, right? We haven't seen problems with the RPM package on other Linux distribution's yet. At least, the el7
one works perfectly on openSUSE.
Still, I think openSUSE can provide an official instruction on removing the pre-installed azure-cli
package if customer wants to use the one distributed by us (Microsoft) at https://packages.microsoft.com/yumrepos/azure-cli/.
Thanks @glaubitz, we really appreciate your contribution to make Azure CLI available on openSUSE.
Customers are advised to report issues with the Azure packages in openSUSE/SUSE with SUSE's Bugzilla database.
Do you mind letting us know the official link or instruction for reporting Azure CLI issues to SUSE's Bugzilla database?
Use https://bugzilla.suse.com and report against the the Cloud:Tools
component after choosing openSUSE Leap as the distribution.
So, the bug here is that Microsoft's own RPM packages are missing the necessary
Conflicts
field in their RPM spec file so that installation of Microsoft's own RPM packages will cause the package manager to remove SUSE's Azure packages from the system.Could you provide more information on how we could leverage the
Conflicts
field? Actually,azure-cli
andazure*
packages are released at very rapid pace. We can't exhaust all possible combinations and figure out which combination is compatible or not.
It looks like you are combining azure-cli-core
and azure-cli
into one RPM while we have separate packages for that in openSUSE. So, you should add azure-cli-core
to the Conflicts
field of your RPM spec file.
Also, according to the naming scheme of Microsoft's own
azure-cli
packages, these packages are built for RHEL7 ("el7") [1], so I'm not sure why Microsoft recommends installing these packages on openSUSE/SLE in the first place.This is simply because the RPM packages works universally, right? We haven't seen problems with the RPM package on other Linux distribution's yet. At least, the
el7
one works perfectly on openSUSE.
There is no guarantee that it works though. You get this guarantee only if you build the packages on the distribution where you want to ship them.
Still, I think openSUSE can provide an official instruction on removing the pre-installed
azure-cli
package if customer wants to use the one distributed by us (Microsoft) at https://packages.microsoft.com/yumrepos/azure-cli/.
There is no need for these instructions if you just add the proper Conflicts
. This way, the installation of your packages will automatically cause the openSUSE packages to be removed.
There is no need for these instructions if you just add the proper
Conflicts
. This way, the installation of your packages will automatically cause the openSUSE packages to be removed.
This is actually not that easy. Adding azure-cli-core
to Conflict
to RPM and then installing our RPM will only remove azure-cli-core
, right? Other dependencies like azure-mgmt-*
can also causes all kinds of issues. It's difficult for us to enumerate all dependencies in Conflict
.
There is no need for these instructions if you just add the proper
Conflicts
. This way, the installation of your packages will automatically cause the openSUSE packages to be removed.This is actually not that easy. Adding
azure-cli-core
toConflict
to RPM and then installing our RPM will only removeazure-cli-core
, right? Other dependencies likeazure-mgmt-*
can also causes all kinds of issues. It's difficult for us to enumerate all dependencies inConflict
.
Hmm, I wasn't aware you have included the Azure SDK in your azure-cli
package as well.
In this case, I suggest adding python-azure-core
, python-azure-common
and python-azure-mgmt-core
to Conflicts
. This should remove most of the SDK packages.
We have so many dependencies:
I am afraid all of them may potentially break azure-cli
.😥
We have so many dependencies:
I am afraid all of them may potentially break
azure-cli
.disappointed_relieved
You don't have to add all of these to Conflicts
. It's sufficient to add python-azure-core
, python-azure-common
and python-azure-mgmt-core
since all the other packages depend on these packages. Thus, if these three packages get removed, all the other packages are automatically removed as well.
I just checked, after removing these three packages, only the devops
and the -nspkg
packages remain.
Thus, you need to add the following to Conflicts
:
Conflicts: azure-cli
Conflicts: azure-cli-core
Conflicts: python-azure-common
Conflicts: python-azure-core
Conflicts: python-azure-mgmt-core
Conflicts: python-azure-datalake-store
Conflicts: python-azure-devops
Conflicts: python-azure-functions-devops-build
Conflicts: python-azure-keyvault-nspkg
Conflicts: python-azure-messaging-nspkg
Conflicts: python-azure-mgmt-datalake-nspkg
Conflicts: python-azure-mgmt-nspkg
Conflicts: python-azure-mixedreality-nspkg
Conflicts: python-azure-nspkg
Conflicts: python-azure-purview-nspkg
Conflicts: python-azure-storage-nspkg
Conflicts: python-azure-synapse-nspkg
Thanks @glaubitz for the analysis.
There is no guarantee that it works though. You get this guarantee only if you build the packages on the distribution where you want to ship them.
I am actually currently working on https://github.com/Azure/azure-cli/pull/20918 to build distribution-specific RPM packages. Perhaps we can make a separate spec for openSUSE.
Conflicts: azure-cli
Well, it can't conflict itself, right? 😉
But still, we are constantly introducing new azure-*
packages, any of them may potentially break azure-cli
. Maintaining the list certainly needs lots of effort.
Do you recommend the usage of
sudo zypper rm -y --clean-deps azure-cli
as this seems to be the best workaround for now?
Thanks @glaubitz for the analysis.
There is no guarantee that it works though. You get this guarantee only if you build the packages on the distribution where you want to ship them.
I am actually currently working on #20918 to build distribution-specific RPM packages. Perhaps we can make a separate spec for openSUSE.
Great idea! Let me know if I can be of any help!
Conflicts: azure-cli
Well, it can't conflict itself, right? wink
Oops, sorry. You're right, of course ;).
But still, we are constantly introducing new
azure-*
packages, any of them may potentially breakazure-cli
. Maintaining the list certainly needs lots of effort.
Yes, but you are not introducing many new -nspkg
and -core
packages. As long as the new packages depend on such common packages, generating the proper Conflicts
list shouldn't be too difficult.
We could also maybe have a meta package that all Azure packages depend on. If the meta package gets purged, the whole SDK and CLI packages would be removed as well.
Do you recommend the usage of
sudo zypper rm -y --clean-deps azure-cli
as this seems to be the best workaround for now?
Sure. I would not put it into any scripts though but just as an instruction step on the homepage.
FWIW, the Azure SDK and CLI packages are not shipped by default with regular openSUSE and SLE distributions. This affects just the images in the public clouds.
Describe the bug
Following https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-linux?pivots=zypper, a freshly installed Azure CLI fails with
This is because SLES (SUSE Linux Enterprise Server) 15 SP3 VM has a pre-installed Azure CLI 2.16.0 which is outdated and conflicts with latest version.
After installing the latest version,
/usr/lib/python3.6/site-packages/azure/cli/__main__.py
is removedleaving
/usr/lib/python3.6/site-packages/azure/cli
a regular package, conflicting with the latest Azure CLI which is a namespace package under/usr/lib64/az/lib/python3.6/site-packages/azure/cli
(https://github.com/Azure/azure-cli/pull/14372).Solution
Remove the pre-installed Azure CLI before installing the latest one:
If you have already installed the latest one, revert back to the pre-installed one first and reinstall the latest one:
The package name may vary on different system version, run
zypper --no-refresh info azure-cli
on a new SLES 15 SP3 VM to check the source package format: