V Wed, Jun 14, 2023 at 10:29:31AM +0200, Dan Čermák napsal(a): > Petr Pisar <ppisar@xxxxxxxxxx> writes: > > The only drawback is one have to decide before GA which software will > > have an alternative content and create meta-packages for the default > > streams. Otherwise, users installing from GA media and upgrading later > > could get installed a nondefault stream. > > Why is that? > My wording was not completely correct. I'm sorry. The problem is what people mean with "upgrade". "dnf upgrade" is fine. "dnf upgrade application" is not fine. "dnf install application" is also not fine. I will start with explaining simpler "dnf install application": - A user has installed fedora-release which never heard about stack. - There is an application in a repository which requires stack. - The user installs the application and stack is pulled in as a dependency. Now the same procedure when the first step is before adding stack2 into the repository, but the installation happens after that: - A user has installed fedora-release which never heard about stack. - The distributor adds stack2, an alternative to stack (Provides: stack = 2), and updates fedora-release to suggest stream-stack-default. - The user installs the application. As a result stack2 is pulled in. The reason is that stack2 provides "stack = 2" which is higher than "stack = 1" provided by stack package. Now the user end up with the same application but stack2 instead of stack. A situation with "dnf upgrade application" would be fine if application depended on stack from the very beginning. But what if the dependency on stack was added to application in between: - A user has installed fedora-release which never heard about stack. - User has installed application. No stack was pulled in because there was no need for it. - The distributor adds stack2, an alternative to stack (Provides: stack = 2), and updats fedora-release to suggest stream-stack-default. The distributor also updates application to depend on stack. - The user updates the application. As a result stack2 instead of stack is installed. The reason is the same very same as in "dnf install application" case -- DNF could choose beetween stack and stack2, so it choose the one with a higher version. Frankly, I would consider automatic selection of the highest alternative to be a welcome feature, not a bug. At the end, the user only requested application, so he does not care about a version of stack. If the stack version mattered, the user should have specified it explicitly. E.g. "dnf install application stack". But things then get complicated when users split transactions into multiple steps. E.g.: # dnf install stack # dnf install application would end with application and stack, but: # dnf install application # dnf install stack would end with application, stack2 and then an error "stack conflicts with stack2". DNF operations are not commutative. And people expect to have their installation procedures reproducible. You might also ask why would somebody invoke "dnf upgrade application" instead of "dnf upgrade". Well, some people read security alerts, evaluate a risk, and then explicitly update selected packages. That's how they end up with "dnf upgrade application". -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
