2:16 p.m.
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 <mschwendt(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org