A few issues I remember caused by unversioned Obsoletes (before they
were banished to Hell) were:
- Not being able, ever again, to provide the thing being obsoleted. And
believe me, things change ;-)
- The Obsoletes affects other channels as well, not only the content of
the channel that contains the package that contains the Obsoletes is
affected.\
If the obsoleted name is needed by something in some other package even
being at a higher version it cannot be installed.
So for a decade or more (I list track, I am here for almost 2 decades),
the Obsoletes always comes with a '=' or a '<='.
Regards,
Fernando
On 2017-03-31 3:08 PM, Igor Gnatenko wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Fri, 2017-03-31 at 19:41 +0100, Tomasz Kłoczko wrote:
On 31 March 2017 at 17:57, Michael Schwendt <mschwe...@gmail.com>
wrote:
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.
OK. Could you please show me example? Best if it will be documented
for
example in bugzilla.
I'm almost sure that it is kind of mistake or results
misinterpretation.
It is yet another possibility tat it may be result of using yum/dnf
which
are working not exactly the same as rpm.
[..]
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.
I have no idea about what kind scenario you are talking about so I
made my
tests.
As I wrote engineering is about testing so here is my test case:
Four spec files and two scripts.
First one has:
rm -f ~/rpmbuild/RPMS/x86_64/test*
rpmbuild -ba --quiet test-1.0.spec test-2.0.spec test-3.0.spec
sudo rpm -Uvh ~/rpmbuild/RPMS/x86_64/test*1.0*
rpm -qa | grep ^test
sudo rpm -Uvh ~/rpmbuild/RPMS/x86_64/test*2.0*
rpm -qa | grep ^test
sudo rpm -Uvh ~/rpmbuild/RPMS/x86_64/test*3.0*
rpm -qa | grep ^test
Here is my result:
$ sh ./test.sh
rpm: no packages given for erase
Preparing... ###############################
##
[100%]
Updating / installing...
1:test-1.0-
1 ################################# [
33%]
2:test-devel-1.0-
1 ################################# [
67%]
3:test-static-1.0-
1 #################################
[100%]
test-1.0-1.x86_64
test-devel-1.0-1.x86_64
test-static-1.0-1.x86_64
Preparing... ###############################
##
[100%]
Updating / installing...
1:test-2.0-
1 ################################# [
20%]
2:test-devel-2.0-
1 ################################# [
40%]
Cleaning up / removing...
3:test-static-1.0-
1 ################################# [
60%]
4:test-devel-1.0-
1 ################################# [
80%]
5:test-1.0-
1 #################################
[100%]
test-2.0-1.x86_64
test-devel-2.0-1.x86_64
Preparing... ###############################
##
[100%]
Updating / installing...
1:test-3.0-
1 ################################# [
20%]
2:test-devel-3.0-
1 ################################# [
40%]
3:test-static-3.0-
1 ################################# [
60%]
Cleaning up / removing...
4:test-devel-2.0-
1 ################################# [
80%]
5:test-2.0-
1 #################################
[100%]
test-devel-3.0-1.x86_64
test-static-3.0-1.x86_64
test-3.0-1.x86_64
And second test on with test-2.0-ver.spec which has changed:
--- test-2.0.spec 2017-03-31 18:55:05.986642900 +0100
+++ test-2.0-ver.spec 2017-03-31 18:55:52.877882709 +0100
@@ -3,7 +3,7 @@
Version: 2.0
Release: 1
License: Test
-Obsoletes: test-static
+Obsoletes: test-static < 2.0-1
%description
Test package.
Result:
$ sh ./test-ver.sh
Preparing... ###############################
##
[100%]
Updating / installing...
1:test-1.0-
1 ################################# [
33%]
2:test-devel-1.0-
1 ################################# [
67%]
3:test-static-1.0-
1 #################################
[100%]
test-static-1.0-1.x86_64
test-devel-1.0-1.x86_64
test-1.0-1.x86_64
Preparing... ###############################
##
[100%]
Updating / installing...
1:test-2.0-
1 ################################# [
20%]
2:test-devel-2.0-
1 ################################# [
40%]
Cleaning up / removing...
3:test-static-1.0-
1 ################################# [
60%]
4:test-devel-1.0-
1 ################################# [
80%]
5:test-1.0-
1 #################################
[100%]
test-devel-2.0-1.x86_64
test-2.0-1.x86_64
Preparing... ###############################
##
[100%]
Updating / installing...
1:test-3.0-
1 ################################# [
20%]
2:test-devel-3.0-
1 ################################# [
40%]
3:test-static-3.0-
1 ################################# [
60%]
Cleaning up / removing...
4:test-devel-2.0-
1 ################################# [
80%]
5:test-2.0-
1 #################################
[100%]
test-3.0-1.x86_64
test-devel-3.0-1.x86_64
test-static-3.0-1.x86_64
As you see result is EXACTLY the same.
In attachment you have tar with 4 spec files and two test scripts.
It is some possibility that you may be right in some scenario which I
still
do not understand so please try to change test case to the form when
it
will start failing presenting exact scenario which is possible to
correct/avoid by using versioned Obsoletes.
PS ATM I'm ready to bet with at least 1:10 ratio that it is some
misunderstanding of some very simple case.
So I'm moving my words one step back and putting this case in WIP
state
asking for exact example implemented in test case.
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.
If package is present in rpm database only in form of "Provides:
A-<version>-<release>" for resolver effectively it is like such
package is
really installed. Ergo: it changes nothing. In both cases will be
done
exactly the same operation o resolving packages dependencies and
write new
state of installed packages.
Please provide libsolv testcases (something like https://github.com/ope
nSUSE/libsolv/blob/master/test/testcases/yumobs/split.t), create FPC
ticket, attach testcases, their results and proposal (new wiki page
regarding guidelines), subscribe DNF developers and only after that we
can talk about anything.
kloczek
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
- --
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAljeqSYACgkQaVcUvRu8
X0xq0A//b9RBpFX7XVQDPKQw2K1vlefaZmr6/zwq4qURKnnf1yFRTa1noH1lY/kw
jTa8azbXJuRN046AN3xhxmRhl6wsx5rpmAUl+s2Kvy2r3XF9oJqPPfLOObke85tL
f5WnOdAsHfFaAJlAv1H/YCpF8kfxoc3hhDWPZp0YmVwOyQOVdLh+b0hRKvXgPKQz
dO9v+FQAcA/PuHvNcJDTs3zHbsBJv7QHQ2E9Bi4IAO9oJEaW8o/ObHj7dkM6NFrU
2C5PPRAE+dnqDO7NGUA5jY/MXDeiXTgU0HJTvaqinQYmrGueSwYfzUauUlVDbSLN
ndl9oaBnPJPsB/53ovviMgSKg4EbAL4P7NRcUgbLwJjQ1eH4DwNifK9oh7sCuea8
u59QXnN97rEQH7rW3UpxhSeJQTO2sE32/Ug8QC8Zb4WOn3cljVeHrcqH6BO8Xn1n
eN0yaaIjbWyXlwX88uR/wZu80M0Gy3GdvtxZ8hoQDiO0X0iRs050QCP5Rb9uS2mF
EDKgcAjdNsXHBiEGcDXWKDF/70FnspZFRKvEhNkH9vZpzJ+47hkTXPmH52EJQYoW
0tJ2TN1pUvuCWX9M5uKmqNX1qD/pQG+kW+CwvWb2eLXyss6BI0wpWOoSONTo7siY
qEXqhWYuOeKFtn461G+mMktJ2ESmRfg768EQQaVNSeh+7b53hDM=
=TxfK
-----END PGP SIGNATURE-----
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
