Bug 2720

That's bug 2317.

Can someone from the sysadmin team link
libiodbc2 for i586 and lib64iodbc2 for x86-64, 
and virtuoso-opensource
from Core Release to Core Updates.

Keywords: (none) => validated_update
CC: (none) => davidwhodgins, sysadmin-bugs

(In reply to comment #1)
> That's bug 2317.
> 
> Can someone from the sysadmin team link
> libiodbc2 for i586 and lib64iodbc2 for x86-64, 
> and virtuoso-opensource
> from Core Release to Core Updates.

Are you able to reproduce ?
Because as i said i *did* not add any new require to virtuoso so it should not happen.
I'll try in a vbox asap if i can reproduce.

CC: (none) => balcaen.john

by  « i said » i mean on irc when we talked about this bug: i did not add any new requirement on virtuoso so far i remember so it should not happen at all (& then the move of thoses files to cores_updates is probably not necessary.

I just installed & update a DVD x86_64 with the default kde4 setup & i can't reproduce this problem with upgrading via the mgaaplet.
The only failure is still the kipi-plugin-expoblending :/

i forgot to mention that this happened on my work machine and i thought it was bug 2317 right away. but i couldn't reproduce with any other machine... and i had already done the "urpmi --auto-select" upgrade on that machine.

(In reply to comment #2)
> (In reply to comment #1)
> > That's bug 2317.
> > 
> > Can someone from the sysadmin team link
> > libiodbc2 for i586 and lib64iodbc2 for x86-64, 
> > and virtuoso-opensource
> > from Core Release to Core Updates.
> 
> Are you able to reproduce ?
> Because as i said i *did* not add any new require to virtuoso so it should not
> happen.
> I'll try in a vbox asap if i can reproduce.

A new requires is not the only way to trigger bug 2317.

The version or release in Mageia is newer, so if any package not available in
Mageia 1, on the system has a version and/or release specific requires on a package,
that stops that package from getting replaced during the upgrade.

Somewhere in task-kde4 or one of it's dependencies, there's a package that
has a specific version and/or release requires.  Since that version/release
is not available in updates, but 2317 gets triggered.

The only way to guarantee all needed dependencies are available, would be to link
everything shown by urpmq --requires-recursive task-kde4.

As that's 1406 packages, it isn't practical.  We can only do it for newly added
dependencies, and those we learn the hard way, also trigger the bug.

That's why but 2317 needs to be solved quickly, with a change to MageiaUpdate
and/or urpmi.

What were the versions of lib64iodbc2 and virtuoso-opensource installed ? Or why were they not installed if it was already required by previous task-kde4 ?

CC: (none) => boklm

(In reply to comment #6)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > That's bug 2317.
> > > 
> > > Can someone from the sysadmin team link
> > > libiodbc2 for i586 and lib64iodbc2 for x86-64, 
> > > and virtuoso-opensource
> > > from Core Release to Core Updates.
> > 
> > Are you able to reproduce ?
> > Because as i said i *did* not add any new require to virtuoso so it should not
> > happen.
> > I'll try in a vbox asap if i can reproduce.
> 
> A new requires is not the only way to trigger bug 2317.

> The version or release in Mageia is newer, so if any package not available in
> Mageia 1, on the system has a version and/or release specific requires on a
> package,
> that stops that package from getting replaced during the upgrade.

> Somewhere in task-kde4 or one of it's dependencies, there's a package that
> has a specific version and/or release requires.  Since that version/release
> is not available in updates, but 2317 gets triggered.

As i said i did not do add/any changes of this type during the task-kde4 update (& the whole kde4 update in fact).
The only way to trigger it would have to install one of the temporary package where i switch a requires to a suggests for soprano-plugin-virtuoso & then used the urpme -auto-orphans to get it removed.
Then indeed you can trigger bug 2317 because virtuoso would get removed.
Here i simply install a dvd & choose the default kde4 setup.
The only package problem i triggered was the one with kipi-plugin-expoblending.
If task-kde4 was *affected* by the same bug it should also be triggered.
Of course if a user try to uninstall some soprano related package it can still be triggered but in this case we won't be able to cover all case (until mgaapplet is able to check */release )



> The only way to guarantee all needed dependencies are available, would be to
> link
> everything shown by urpmq --requires-recursive task-kde4.

Well the first step here would be that the packager & the QA team after to install package from testing with 

urpmi --use-media "Core Testing" yourpackage

This way we'll be able to catch *most* of broken requires (QA team need at least to start from a fresh mageia by way :/ )

> 
> As that's 1406 packages, it isn't practical.  We can only do it for newly added
> dependencies, and those we learn the hard way, also trigger the bug.
> 
> That's why but 2317 needs to be solved quickly, with a change to MageiaUpdate
> and/or urpmi.

Sure.

(In reply to comment #7)
> What were the versions of lib64iodbc2 and virtuoso-opensource installed ? Or
> why were they not installed if it was already required by previous task-kde4 ?

I'll try and look in the logs to see if it lists something about this, the problem is that i can't reproduce it, because i did execute the updates with "urpmi --auto-select", there i confirmed that those 2 files were installed from Core Release; thus they had not been available.

This machine is the one i use at work, and is recent, so i'm 100% certain that:
 - it was installed with the DVD installer as a default KDE installation, without updates.
 - the installation was without hiccups
 - i have enabled tainted repositories afterwards
 - i have updated it afterwards (which was about 2 or 3 weeks ago), using the applet.
 - no other things have been done, no orphans have been removed, no packages from other sources were installed, other than "(core/core32/nonfree/tainted) (release/updates)"

i'll try and find out if there's something in the logs indicating what happened...

(In reply to comment #9)
> i'll try and find out if there's something in the logs indicating what
> happened...

Can you attach /root/drakx/install.log?

(In reply to comment #8)

> Well the first step here would be that the packager & the QA team after to
> install package from testing with 
> 
> urpmi --use-media "Core Testing" yourpackage

Ever since bug 2317 was opened, qa have been watching for packages
being installed from the Release repositories.

The problem is, that the only way to recreate this problem is to start
with a Mandriva 2010.2 system, with task-kde4 installed AND the package
called root.

When the op upgraded from Mandriva, the version specific dependencies
of the package called root (or one of it's dependencies) prevented the
Mandriva versions of libiodbc2 from being upgraded.

Now, when an upgrade of task-kde4 is being installed using mgaapplet,
it (or one of it's dependencies) has a version specific requires, or
selects the package because it has a higher release, or version, for
a package that is only in Core Release, so the update fails.

This didn't happen during beta testing, as none of the people doing
the beta testing had the package called root installed from Mandriva.

I may be wrong about which package prevented the dependencies from
being installed, but that doesn't matter.  Some Mandriva package
(not available in Mageia 1) has version specific requires, which
blocked the update during the upgrade to Mageia.

The only possible methods of dealing with this (as I see it) ...
- Alter MegeiaUpdate to do the equivalent of urpmi --auto-select
- link all of the Release packages in the Release repositories 
  in corresponding Updates Testing and Updates repositories.
  (Massive synthesis.hdlist.cz files)
- Create installations of Mandriva 2010.2 with all possible combinations
  of packages, and test every update on each installation.
  (Not possible with time/diskspace)
- For each  update, get a list of every dependency, then get a list of
  every package that requires that dependency on Mandriva 2010.2, and
  check each of the .spec files for version dependant requires, and
  link those packages only, to both Updates Testing, and Updates.
  (Very time consuming for QA).

While changing MageiaUpdate to do the equivalent of urpmi --auto-select
will have an impact on speed, it is the only reasonable solution, in
my opinion.

I tried to provide a patch to fix the problem, it failed, as it also
picked up suggestions from non-enabled repositories. While I can usually
figure out what perl code does, I'm not a perl programmer.  We need
someone who knows perl and urpmi, to fix this, and quickly.

I'm sorry but from what i understand initially AL13N started directly from a mageia alpha/beta/final and not an upgrade from a mandriva 2010.2 & that's why i'm saying the problem can't be related to bug #2317.
If AL13N did upgrade from mandriva 2010.2 of course it can be related to this bug, but if it did start from a Mageia (& this what i understand initially) i failed to see where #2317 can explain this problem with a default install.

So al13n did you upgrade from mandriva initially or started with a fresh cauldron install ?

Listen, as i've said already SEVERAL times in this bugreport:

This machine has been cleanly installed from the final (about a month ago).
After this, i've enabled tainted repos and updated once, using the applet. (only official repositories).

At the time of the bug: I used the applet, and when I fired it up: It gave an error message about 2 packages and thus deselected 2 or 3 packages, task-kde4 being one of them, an other being task-kde4-minimal. I quit it, and reopened the applet update, same thing happened.

After this, i went into a console and typed:
[ ]# urpmi --auto-select

and it gave me 2 packages from medium "Core Release" and 2 or 3 others from "Core Updates" (the task-kde4 packages)

I then proceeded to install those packages.

And then i reported the bug.

mikala: i'm not saying you did something wrong, but as the expression goes: if it looks like "dung" and smells like "dung", it IS "dung".

the update didn't work, due to apparently dependencies or dependencies of suggests or from those task-kde4 packages being only in the "Core Release".

that makes it bug 2317 by definition, even if you or i can't reproduce it...

Again, i'm 100% certain this machine has not been messed with, this is my work PC and it's very recently installed.

Perhaps bug 2317 has more implications than we thought, or some other bug is the cause of bug 2317 being fired, but before we jump to conclusions, let me hope to find something in the logs that would effectively show what happened.

ok could you attach the /root/.drakx/install.log
so we can check the package installed during the installation.

Created attachment 812 [details]
/root/drakx/install.log

Created attachment 813 [details]
part_of_messages

From the original report ...
2 packages could not be found in updates:
- lib64iodbc2
- virtuoso-opensource

From install.log ...
lib64iodbc2-3.52.7-2.mga1.x86_64
virtuoso-opensource-6.1.2-1.mga1.x86_64

From messages ...
Sep 12 10:34:27 localhost perl: [RPM] lib64iodbc2-3.52.7-2.mga1.x86_64 installed
Sep 12 10:34:27 localhost perl: [RPM] virtuoso-opensource-6.1.2-1.mga1.x86_64 installed

So these two packages were installed from Core Release during the upgrade.

How did they get uninstalled?  Were they mistakenly auto-orphaned?

Dave: please don't get confused again :-) this is an install, not an upgrade!

upgrading is a term only used when upgrading from mdv to mga. updating is all other updating, and install is when there's nothing before it. :-)

but it does seem like they were installed, which should be normal, since it's installed from DVD.

right after installation, i did an upgrade, so perhaps they got removed during that upgrade? i didn't think i did an auto-orphan, but maybe i did after the first update (immediately after installation)

i tried looking in logs to find out what or why, but i can't find anything. where should i look? (apart from /var/log/messages , which is that second attachment...)

perhaps it was longer ago and thus not on logs anymore :-(

Try "zgrep lib64iodbc2 /var/log/syslog*"

can't find anything like it... :-(

perhaps someone could try installing from a DVD, don't update, doing autoclean and then update? maybe it can be triggered like that...

if not, then i think this is unreproducable... :-(

I just did a clean dvd install of kde4, gnome, lxde.
No updates during install.
After rebooting, added a full set of sources (including tainted).

Waited for mgaapplet to detect the updates.

Installed 568 updates without any problems.

the only thing i can think of is autoclean after some updates from a month ago or something. but it's not checkable again... i wish we could really fix this issue, it seems like that person on the mailing lists also had this problem and didn't want to bugreport it...

Without more info of how those packages were uninstalled, there's no
way to track down the problem.

I'm going to close this report as old.  If it happens again, and more info
becomes available, feel free to reopen it.

Status: NEW => RESOLVED
Resolution: (none) => OLD