Bug 23743

Summary:	python2-smmap and python2-smmap2 packages conflict/don't have obsoletes/breaks update from mga6
Product:	Mageia	Reporter:	Christian Lohmaier <lohmaier+mageia>
Component:	RPM Packages	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED FIXED	QA Contact:
Severity:	major
Priority:	Normal	CC:	geiger.david68210, marja11
Version:	Cauldron
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:
Source RPM:	python-smmap2-2.0.3-2.mga7.src.rpm	CVE:
Status comment:
Attachments:	console output of the urpmi commands mentioned in the description

Description Christian Lohmaier 2018-10-21 16:43:08 CEST

Description of problem:
severity major because it breaks update from mga6

python2-smmap and python2-smmap2 seem to be the same project from different repositories/forks that both try to install into the same place. 

Version-Release number of selected component (if applicable):
python-smmap2-2.0.3-2.mga7.src.rpm and
python-smmap-0.9.0-4.mga7.src.rpm as of this writing

How reproducible:
have a system that has python-gitpython-1.0.2-1.mga6 installed (that in turn require python-gitdb and that python-smmap >= 0.8.0, so you have a system with 
python-smmap-0.9.0-1.mga6 installed)

Steps to Reproduce:
1. try to update. urpmi --auto-update selects both python2-smmap as well as python2-smmap2 to be installed.
2. trying to skip installation of python2-smmap failes becuase python2-smmap still conflicts with the files from mga6 package since python2-smmap2 is not set to be a replacement
3. trying to skip installation of python2-smap2 package will make the update of python-gitdb fail, since version in mga7/cauldron requires python2.7dist(smmap2)[>= 2.0.0] 

tldr;
Solution is to drop package python2-smmap and add proper obsoletes for "python-smmap" to python2-smmap2

Comment 1 Christian Lohmaier 2018-10-21 16:45:45 CEST

Created attachment 10416 [details]
console output of the urpmi commands mentioned in the description

output of 
LC_MESSAGES=C urpmi --auto-update
LC_MESSAGES=C urpmi --auto-update --skip /python2-smmap-/
LC_MESSAGES=C urpmi --auto-update --skip /python2-smmap2-/

to illustrate the update issue showing the conflicting files.

Comment 2 David GEIGER 2018-10-21 17:15:08 CEST

Should be fixed in next update with python-smmap2-2.0.3-3.mga7

CC: (none) => geiger.david68210

Comment 3 Marja Van Waes 2018-10-21 21:48:15 CEST

(In reply to David GEIGER from comment #2)
> Should be fixed in next update with python-smmap2-2.0.3-3.mga7

Thanks David :-)

Closing.

CC: (none) => marja11
Resolution: (none) => FIXED
Status: NEW => RESOLVED

Comment 4 Christian Lohmaier 2018-10-22 14:08:12 CEST

can confirm that the update issue is fixed, (but not the duplication of the package)
$ urpmq -ayr smmap
python2-smmap-0.9.0-4.mga7
python2-smmap2-2.0.3-3.mga7
python3-smmap-0.9.0-4.mga7
python3-smmap2-2.0.3-3.mga7

Comment 5 David GEIGER 2018-10-22 14:13:59 CEST

and what is the output of:

$ rpm -qa |grep smmap

Comment 6 Christian Lohmaier 2018-10-22 22:32:05 CEST

sorry for being unclear - the update did only install python2-smmap2, so my update issue is resolved.

To me it just doesn't make sense to have the package duplicated (and at least a urpmq --whatrequires doesn't list any uses for the python[23]-smmap ones).

And even if some package would depend on it, you couldn't install it alongside python2-gitdb (i.e. a package that requires the smmap2 one).

So I guess I'm missing the point in providing the -0.9.x version

Comment 7 David GEIGER 2018-10-22 23:26:39 CEST

(In reply to Christian Lohmaier from comment #6)
> 
> So I guess I'm missing the point in providing the -0.9.x version

Already done! see:
http://svnweb.mageia.org/packages/cauldron/python-smmap2/current/SPECS/python-smmap2.spec?r1=1323348&r2=1323347&pathrev=1323348

Comment 8 Christian Lohmaier 2018-10-23 11:27:16 CEST

The patch/change you linked to fixes the provides/obsoletes, but it doesn't nuke the python2-smmap or python3-smmap versions from the repositories.

But his also has also been done I see:
http://svnweb.mageia.org/packages?view=revision&revision=1323382

It's just not reflected on mirrors/the repository. That's the source of the confusion.