SUMA in general 3 and 4
I don’t know if this the right place, but I would like to formally request that package hub no longer be a required repository.
I have continued to run into problems where packagehub is concerned.
SP upgrades\migrations seem to require PackageHub to be a downloaded and synced in order to proceed with an upgrade. We don’t want to use it or even have it available. Another issues we had was when packages that were in package hub were moved out and into a opensuse repo that caused upgrades to be problematic until we removed them.
We don’t want PackageHub available for use because of these issues and foremost SUSE doesn’t support any of the packages in it.
Could you please elaborate on how PackageHub seems to be required to be downloaded and synced in order to proceed with an upgrade? We in fact advise against using PackageHub on the Server or Proxy
Hi
On the SuMA (3.2.11 here) Admin → Setup Wizard → SUSE Products page, in the list of repositories there is no option to ‘un-ckeck’ the mandatory channel for SLES, you can for SLED 15 and on ARM (15 and 15.1)…
Not an easy task, but I do have a ticket open regarding PackageHub and showed support the issues I’m running into.
Whats happens is if you do not have PackageHub downloaded and attempt to preform a SP migration through SUMA the target (in my case SUSE 12 SP5) will actually be grayed out. If you hover your mouse over the grayed out target it states that PackageHub is not synced. Once you download PackageHub the target OS/sp becomes available.
Like I said I showed Support this yesterday and they couldn’t explain it and thought it was not supposed to work this way as well. We’ll see what they come up with.
As of right now there is a problem with the checksum of several packages in 2 Package Hub Repos that are being address. SUSE12 SP4 & 5
Not sure why they were still there nor do I know what exactly they are as they don’t appear to have any actually packages. But once I removed them I was able to SP migrate the system without PackageHub downloaded.
Not sure if this means there is another issue or not.
Those two packages look like the “product packages”, which IIRC get installed once you connect the according child channel to a client. Removing that child channel from the client doesn’t remove those product packages, like it won’t remove any actual program packages.
In the end, the SP Migration dependency checker noticed the “installed product” and requested the channels to update that product as well.