Description of problem: There should only be one version in core. The same situation existed in Mga 5, and was (can still) cause problems when testing packages from backports or updates_testing that were at one time obsoleted in the older version. The Mageia 5 situation has been partly mitigated by synchronizing the two versions, but it's not ideal, as when no version of task-obsolete is installed (default) either the old or new version may be installed by urpmi --auto-update depending on the particular obsolete involved. To avoid this mess continuing into Mageia 6 can we please nuke the tainted task-obsoletes from the Cauldron mirrors. Version-Release number of selected component (if applicable): barjac> :v task-obsolete -dMga -rcauldron <Sophie> 6-31.mga6 // core-release (Mga, cauldron, i586), core-release (Mga, cauldron, x86_64) <Sophie> 5-41.mga5.tainted // tainted-release (Mga, 5, x86_64), tainted-release (Mga, 5, i586), tainted-release (Mga, cauldron, i586), tainted-release (Mga, cauldron, x86_64) How reproducible: See https://bugs.mageia.org/show_bug.cgi?id=1067#c35 and onwards for example of problem. Steps to Reproduce: 1. 2. 3. Reproducible: Steps to Reproduce:
(In reply to Barry Jackson from comment #0) > Description of problem: > There should only be one version in core. > > The same situation existed in Mga 5, and was (can still) cause problems when > testing packages from backports or updates_testing that were at one time > obsoleted in the older version. That's why there should _Always_ be versioned obsoletes in task-obsolete. if there is not, it should be fixed. > The Mageia 5 situation has been partly mitigated by synchronizing the two > versions, but it's not ideal, as when no version of task-obsolete is > installed (default) either the old or new version may be installed by urpmi > --auto-update depending on the particular obsolete involved. Actually urpmi should always select the tainted one if both are available and same EVR as the end "1.mga6.tainted" is bigger than "1.mga6" in comparision... if it does not, we have a bug in the deps resolver
CC: (none) => tmb
Yes the original obsolete should have been versioned. However, that would not have caused an issue if there was not an ancient version of task-obsolete in tainted. Should the one in tainted be nuked, or should it be there - if so, why?
I guess it exists because it has been used at a time to nuke tainted SRPMs?
(In reply to Rémi Verschelde from comment #3) > I guess it exists because it has been used at a time to nuke tainted SRPMs? Tainted SRPMS? Are there such things? Surely we use the same sources for both tainted and core, only the submit --define section changes. Or am I really missing something? :\
(In reply to Barry Jackson from comment #4) > (In reply to Rémi Verschelde from comment #3) > > I guess it exists because it has been used at a time to nuke tainted SRPMs? > > Tainted SRPMS? Are there such things? Surely we use the same sources for > both tainted and core, only the submit --define section changes. Or am I > really missing something? :\ We use the same SVN source, but when you submit with mgarepo, it's a SRPM that you submit. And the task-obsolete will also work only on packages of its own repo, i.e. to obsolete tainted packages you need a tainted task-obsolete.
(In reply to Rémi Verschelde from comment #5) > (In reply to Barry Jackson from comment #4) > > (In reply to Rémi Verschelde from comment #3) > > > I guess it exists because it has been used at a time to nuke tainted SRPMs? > > > > Tainted SRPMS? Are there such things? Surely we use the same sources for > > both tainted and core, only the submit --define section changes. Or am I > > really missing something? :\ > > We use the same SVN source, but when you submit with mgarepo, it's a SRPM > that you submit. And the task-obsolete will also work only on packages of > its own repo, i.e. to obsolete tainted packages you need a tainted > task-obsolete. OK,but the tainted task-obsoletes get installed, to obsolete core packages by urpmi --auto-updates (if task-obsoletes is not already installed). See comment #1 where tmb says that if tainted is available then tainted task-obsoletes will always be used, irrespective of it's version. However urpmi task-obsoletes installs the newer core version even when tainted is enabled. ...and then that version is used by urpmi --auto-updates even with tainted enabled AND a an obsoleted package listed in the tainted version that is relevant to the transaction.
Ah I missed the EVR bit in tmb's comment so it's not "irrespective of version" but that does not affect the discussion as here the versions are different.
task-obsolete's purpose is to remove packages from users' machines, NOT to remove them from a repo (that's only a side-effect). For its purpose, obsoleting packages in task-obsolete in core will work no matter what repo they came from. There should *NOT* be a duplicate package of task-obsolete in any other repo.
Thanks David. I have asked on numerous occasions in #mageia-dev and #mageia-sysadm for it to be removed from Cauldron tainted (as you are aware) but nothing has happened, hence this bug report. @tmb Regarding unversioned Obsoletes in task-obsolete, there are approx. 120.
The versions are the same, now task-obsolete-6-46.mga6 task-obsolete-6-46.mga6.tainted So the issue from the summary of this report, got fixed. (In reply to David Walser from comment #8) > task-obsolete's purpose is to remove packages from users' machines, NOT to > remove them from a repo (that's only a side-effect). For its purpose, > obsoleting packages in task-obsolete in core will work no matter what repo > they came from. There should *NOT* be a duplicate package of task-obsolete > in any other repo. So the tainted version should be obsoleted by the core version, something like Obsoletes: task-obsolete < 6-47.mga6.tainted ??
CC: (none) => marja11Assignee: bugsquad => pkg-bugs
(In reply to Marja van Waes from comment #10) > > (In reply to David Walser from comment #8) > > task-obsolete's purpose is to remove packages from users' machines, NOT to > > remove them from a repo (that's only a side-effect). For its purpose, > > obsoleting packages in task-obsolete in core will work no matter what repo > > they came from. There should *NOT* be a duplicate package of task-obsolete > > in any other repo. > > So the tainted version should be obsoleted by the core version, something > like > > Obsoletes: task-obsolete < 6-47.mga6.tainted ?? Or, in case it gets accidentally pushed to tainted again: Obsoletes: task-obsolete <= %{version}-%{release}.mga6.tainted ? Should that work? I haven't found an example of only the tainted version of a package getting obsoleted.
Summary: task obsolete in Cauldron has two different versions in core and tainted => task obsolete should only have a core version instead of one for core and one for tainted
Marja, nop we can't remove task-obsolete only from tainted repo, only a sysadmin can directly remove it.
CC: (none) => geiger.david68210
(In reply to David GEIGER from comment #12) > Marja, nop we can't remove task-obsolete only from tainted repo, only a > sysadmin can directly remove it. re-assigning to sysadmin team, then :-)
CC: (none) => sysadmin-bugsComponent: RPM Packages => Release (media or process)Assignee: pkg-bugs => sysadmin-bugs
(can't find the component i was looking for, thought it had to be something else than packages if it's isn't something a packager can do)
Component: Release (media or process) => RPM Packages
dropped from tainted
Status: NEW => RESOLVEDResolution: (none) => FIXED