On 01. 03. 19 16:36, Adam Williamson wrote:
On Fri, 2019-03-01 at 00:35 +0100, Miro Hrončok wrote:
More generally, the *flood* of Python 2 dep issues here is something I
was definitely concerned about with the Python 2 retirement policy
explicitly deciding not to say anything about obsoleting Python 2
subpackages :(
I wanted the py3 packages to obsolte the py2, but i was outvoted.
I now manually add those to fedora-obsoelte-packages, but I do it in batches.
I wait for a compose now to make another batch (fora rawhide and f30).
I think where the upgrade fails because the python2 package is a
subpackage and has a version-specific dependency on another subpackage
from the same source package, that other subpackage should obsolete it.
That's what I did for blockdev: python2-blockdev requires libblockdev
of the same version, so to me it makes sense for libblockdev to
obsolete python2-blockdev in builds where python2-blockdev is not
built:
https://src.fedoraproject.org/rpms/libblockdev/c/46c87cc14b2e4783555221d49fbdff7138fb6c0f?branch=master
do you see any issues with that?
I don't. I completely agree with this approach.
Cool. FWIW, reading the ticket you linked, *this* approach was not
considered (only 'python3 package has obsoletes' versus 'fedora-
obsolete-packages has obsoletes' scenarios seem to have been
considered), so I'm going to consider that it's fine until someone
tells me to stop. ;)
According to the package guidelines, you should stick with a hardcoded
version-release here.
However if you update the package in previous Fedoras, you need to raise the
hardcoded version. I consider that a great PITA.
I do not see that anywhere in the guidelines. In fact there's an
explicit example that uses *this* pattern in the guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages
Provides: oldpackagename = $provEVR
Obsoletes: oldpackagename < $obsEVR
OK, that's not the precise same situation, but it seems to establish a
precedent that relative obsoletes are fine...
The $obsEVR variable here represent the harcoded value if I understand it correctly.
"$obsEVR is an (Epoch-)Version-Release tuple arranged so that there is a clean
upgrade path but without gratuitously polluting the version space upwards. You
usually do not use macros for this as you’re simply trying to advance beyond the
last known release under the old name."
It says "usually", so I guess you are good.
See the entire discussion in https://pagure.io/packaging-committee/issue/754
Thanks! I don't see any note here that any decision was actually made
on the version question, though. The question was asked, but no
resolution to it was reported back to the ticket AFAICS.
Reading the meeting log, it seems like it's more of a policy of tibbs'
that obsoletes in fedora-obsolete-packages should be versioned? Which
is kind of a different thing. I haven't had any need to tell him he's
wrong about that yet. ;) But of course, that's a drawback of f-o-p: you
*can't* do something like "Obsoletes: python2-foo < %{version}-
%{release}" in f-o-p.
Another thing I note from the meeting log is that, AFAICS, no actual
vote was ever taken on any policy or declaration. I don't think your
comment on the issue - "The resolution from the meeting was the
following:
When removing py2 package, don't obsolete it from py3, but rather
obsolete it from fedora-obsolete-packages but only if keeping that
package installed is likely to cause problems on upgrades." - is
actually *correct*. From the log, nothing like that text was ever
actually proposed or voted on at all. The only quasi-formal outcome of
the entire discussion was geppetto's:
#info mhroncok to help tibbs co-maintain fedora-obsolete-packages
#info We acknowledge that there are likely to be a lot of py2 packages
added to fedora-obsolete-packages in the near future
You are right. I wasn't fighting for a formal resolution because I was not happy
about the outcome.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
