On Fri, 31 Mar 2017 17:32:09 +0100, Tomasz Kłoczko wrote:
> I see that you and other people proposing versioned Obsoletes rules never
> ever analysed step by step whole scenario(s) or done kind of 10 min POC to
> prove correctness/incorrectness of this. Looks like again .. it is result
> of using (educated) guessing :(
No, it's based on common experience several packagers have made over a
period of several years. You seem to have missed that period. Non-versioned
Obsoletes have caused problems before.
> Let's try do this here step by step analysing exact scenarios with and
> without versioned Obsoletes.
> Package A, Version 1.0, release 1 has static subpackage
> Package A, Version 2.0, release 1 has no longer static subpackage and main
> A has obsolete rule for A-static
> Package A, Version 3.0, release 1 has again static subpackage and by this
> has no longer has obsolete rule for A-static.
>
> Additional detail:
> For the record: all exactly this kind of packages should have "Requires:
> A-devel = %{version}-%release}" in static and A-devel should have at least
> "Requires: A = %{version}-%{release}". However in or case it is meaningless
> ..
>
> What will happen if in 2.0 will be "Obsolete: A-static < 2.0-1" and just
> "Obsolete: A-static" when new 3.0 will arrive?
>
> What will happen on upgrade from 1.0 to 2.0 if A-static-1.0 was installed
> before? Of course A-static will be uninstalled.
>
> What will happen on upgrade from 1.0 to 3.0? Because A-3.0 no longer
> carries Obsolete rule -> A and A-static will be upgraded together.
No. The exact behaviour is implementation dependent. As long as the
Obsoletes tag is seen by the dependency resolver when examining installed
packages and available packages, the obsolete package is not taken into
consideration when resolving dependencies. Its EVR is irrelevant then.
It will not become an update or upgrade. It is obsolete.
Below you added a wall of text once again. Your passion for this topic
is admirable, but it won't lead to anything, if you refuse to be much more
short and concise.
> BTW Epoch. Using Epoch is only for scenario when it is necessary roll back
> to earlier version of *the same package* when such package *is installed*.
That's not true either. A package doesn't need to be installed at all, and
it doesn't need to be the "same package". In repo metadata highest EVR
wins version comparison. Again, depending on how the package tools and
depsolvers are implemented, you would not even see a package due to its
EVR. Also, there's the scenario of package splits, such as a library
getting released as a separate project with an own versioning scheme,
and Epoch is the only way to handle that, regardless of whether a package
is installed already.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
