Vendor Channel Sync Options

[dhcolesj]

I found out that a forced upgrade of SUMA 5.0 has changed the way vendor channels are synchronized.
Now, it appears, if packages are removed upstream, when you sync they are removed from SUMA EVEN IF you're using them in a Content Lifecycle Project, and need them.
I'm wondering did that come from Uyuni, or is that SUSE? Because it has broken our ability to maintain consistency from dev to test to prod.
I'm Wondering does Uyuni have options on how repo syncs are handled regardless of the upstream? i.e. "just pull new", "exact mirror", etc.

[rjmateus]

Hey, we have changed the behaviour when synchronizing vendor channels, and if a package is removed from upstream then it's also removed from the uyuni/SUMA server.
Packages are not expected to get removed from upstream repository, unless something went terrible wrong with it, and in that case we also want to remove it from SUMA server
For custom channels, this behaviour can be controlled, and we have an option for it at a channel level.

[dhcolesj]

The problem with this approach and not leaving the control in the hands of the users, is reality. I've had Red Hat, Ubuntu, Debian, and SUSE jerk packages for no other reason than there was a new one. Red Hat has renamed repos on the fly with no warning in the past.

I understand the motive, but that should be an option the folks on my end can control. I should be able, like with Satellite (5 & 6), and Spacewalk to override that default. This has caused us a great deal of headache.

[rjmateus]

@admd @mcalmer for awareness
Should we have a parameter to allow users to get back to the old behaviour?

[dhcolesj]

Yes we should. This is not anyone's call outside the organization using the software. I get the sentiment, but in practice of everyday management of servers, it doesn't work. See Ya' Howard Coles Jr. John 3:16!

…

On Thu, Sep 4, 2025, 9:51 AM Ricardo Mateus ***@***.***> wrote: @admd <https://github.com/admd> @mcalmer <https://github.com/mcalmer> for awareness Should we have a parameter to allow users to get back to the old behaviour? — Reply to this email directly, view it on GitHub <#10700 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHFZPBOD32ZM2QW4CZU3OED3RBGVPAVCNFSM6AAAAACDMU2DX2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMZQHA3TMMY> . You are receiving this because you authored the thread.Message ID: ***@***.***>