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:


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...

> 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

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
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to