urpmi --update option should behave like --search-media <list of the update media>

[Jeff Johnson]

A wider search would be speeded up by Bloom filters.
The tainting is a rpm-attributes RFE in disguise

[Pascal Terjan (pterjan42)]

Using urpmi --update (or MageiaUpdate) is almost equivalent to --media <list of the update media>, it would be better if it acted as --search-media <list of the update media>, meaning that it can resolve dependencies using other media

The code almost does it (it sets searchmedia on the update media) except that there are several calls to non_ignored_media($urpm, $options{update}) which means that non update media will be excluded.

Even without changing current behavior, I think it would have made more sense to temporary ignore other media (like with --media) instead of having this option to non_ignored_media().

[Thierry-vignaud (thierry-vignaud)]

Our policy was that update media should be self contained.
Else this bring a hell of issues.
People having part of core (eg: DVD media) may miss some dependancies if update media are not self contained...

[Thomas Backlund (tmb)]

(In reply to comment #1)
> Our policy was that update media should be self contained.

that was the mdv way, yes.
but it's bad, as it adds duplicate rpms on the mirrors & bigger hdlists in updates tree.

yes we could hardlink rpms, but it would need more complex setup on the primary mirror side, and it wouldn't help with the hdlists

> Else this bring a hell of issues.
> People having part of core (eg: DVD media) may miss some dependancies if update
> media are not self contained...

The "add updates only" media option should be dropped from rpmdrake/media manager.
We now tell people to add all online medias to get full support.

Adding full medias only need to download the /release hdlists once as the medias are frozen.

[Stormi (stormi)]

we already have updates failing because of that (packages that add new requires), so if we agree to change the behaviour of --update, it would be good to issue an update of urpmi for Mageia 1.

[Eugeni Dodonov (eugeni)]

The mandriva secteam solution for this problem was to provide all the packages required by an update together with the update itself.

E.g., if updated version of appA now requires appB from main repository, it was simple rebuilt alongside appA and released with it.

This actually make sense from the support point of view, as it ensures that when package gets new requirements, those requirements are available alongside it.

Yes, it causes rpm duplication and such, but still it looks like the correct way to do it for me..

[Boklm (boklm)]

It makes senses if some people use updates media but don't have the release media. But if we say that everybody should have the corresponding release media to use the updates media, it's not useful to provide a copy of the release packages.

[Thierry-vignaud (thierry-vignaud)]

A few remarks:
1) This will make MageiaUpdate wey slower
   (quite a lot more synthesis to parse, quite a lot more of requires
    to parse/compute)
2) Even with that behaviour, we WILL STILL FAILL on some machines
   if user has eg DVD media but not full network media
   and thus some packages may still be missing from DVD
3) Fred Lepied, Frederic Crozat & Warly have decided to remove
   all code that was adding full media and the like, checking for
   missing media, ... b/c of that

It's quite a lot more work to try to make this work than just add/link the missing media to */updates

What's more at this stage, after release.
We've a decade of history & experience of what works and what doesn't, so why try to go the bad way again?

[Thomas Backlund (tmb)]

(In reply to comment #6)
> A few remarks:
> 1) This will make MageiaUpdate wey slower
> (quite a lot more synthesis to parse, quite a lot more of requires
> to parse/compute)

This is a real issue, yes.

> 2) Even with that behaviour, we WILL STILL FAILL on some machines
> if user has eg DVD media but not full network media
> and thus some packages may still be missing from DVD
>
> 3) Fred Lepied, Frederic Crozat & Warly have decided to remove
> all code that was adding full media and the like, checking for
> missing media, ... b/c of that

This is not an issue if we _require_ all online medias to be added,
and remove the option to "add updates media only"

>
> It's quite a lot more work to try to make this work than just add/link the
> missing media to */updates
>
> What's more at this stage, after release.

This is the real important point right now for the already released distro.
Let's do the linking thing for Mageia 1, in order to get it fixed _fast_ in a way we know works.

> We've a decade of history & experience of what works and what doesn't, so why
> try to go the bad way again?

Progress means re-evaluting decisions made earlier to see if things have changed / can be changed. Status quo is not always the best (or worst) option.

The point now is that pretty much every user have full medias added anyway,
so we really should take advantage of that.

But the hdlists/synthesis/metadata issue needs to be reviewed/fixed/optimized.

[Davidwhodgins (davidwhodgins)]

As new dependencies are being added now, to packages in Updates Testing, and
the discussion on the sysadmin mailing list indicates the preference is to
modify the behaviour of mgaapplet, rather then copying the dependencies from
Core Release, the priority of this bug is very high.

It's currently blocking other updates.

[Thierry-vignaud (thierry-vignaud)]

err, one email doesn't exactly define a consensus IMHO...

[Boklm (boklm)]

(In reply to comment #6)
> A few remarks:
> 1) This will make MageiaUpdate wey slower
> (quite a lot more synthesis to parse, quite a lot more of requires
> to parse/compute)

Slower when installing ? or slower when searching for new updates ?

I don't know a lot about urpmi/MageiaUpdate so maybe I'm wrong, but I think it doesn't need to parse synthesis from release repository when searching for new updates, so it shouldn't be slower for this. It would be slower when installing the updates, but it would be the same as in rpmdrake ?

[Mageia (mageia)]

Don't we configure all media (including Core) by default when adding updates media?
The live installer does configure all media at first reboot.
IIRC, the classical installer configures all media as well if network is available;
What is the behavior of the update tool when configuring updates media?

[Michael Scherer (misc-zarb)]

If the sped is the problem, why not simply do like this :
try to install eeything with updates media, if it fail du to missing deps, redo silently with all medias.

This way, installs are still fast most of the time, and we are safe ( but lower ) for the rest.

That seems like the best compromise.

[Stewbintn (stewbintn)]

*** Bug 2155 has been marked as a duplicate of this bug. ***

[Stormi (stormi)]

During latest packager meeting, it was decided that ultimately we would like the behaviour of the --update option to be changed, but before this happens (for this to happen "someone" has to do it) we have to provide the needed dependencies in the updates media.

[Davidwhodgins (davidwhodgins)]

In https://bugs.mageia.org/show_bug.cgi?id=2097#c35
I've created a patch for /usr/sbin/MageiaUpdate
https://bugs.mageia.org/attachment.cgi?id=742&action=diff

Please apply it to rpmdrake-5.26.10-1.mga1.src.rpm
and push to Core Updates Testing.

Thanks, Dave Hodgins

[Davidwhodgins (davidwhodgins)]

Regarding my suggested patch. Hold on.

Per https://bugs.mageia.org/show_bug.cgi?id=2097#c38
while the patch did allow the update to pick up the dependencies from
Core Release, it also then suggested some updates from Backports
Testing, even though the repository was not enabled.

[Stormi (stormi)]

Assigning to maintainer now that our maintainers database has an entry for
this package. Please assign back to <email address hidden> in case of a mistake
from me.

[Stormi (stormi)]

New situation where this bug occurs when the tainted updates media are activated and the tainted version of a package has an update, even if the update does not add new deps.

=> MageiaUpdate needs deps from Tainted Release in order to update to the tainted package.

Steps to reproduce:

urpme libdca0
urpmi vlc --excludemedia Updates,Tainted
MageiaUpdate (with tainted updates media activated)

=> it wants to update vlc to the tainted version and fails because of missing libdca0

[J-manuel (j-manuel)]

hello is the bug 3038 related to this one ?

[Eeeemail (eeeemail)]

I don't think so. This shouldn't affect rpmdrake, only mageiaupdate.

Our script doesn't show any change in recursive dependencies for
apache-mod_userdir either. I would say that is a conflict of some sort.

[Jeff Johnson (n3npq)]

tracked at https://bugs.launchpad.net/rpm/+bug/913230

[Davidwhodgins (davidwhodgins)]

If a package is in Tainted updates with a new requires, and
that requires can be satisfied by a package in Core Updates
does anyone know if that will work or does the package
have to be linked to Tainted Updates too?

[Eeeemail (eeeemail)]

I think we found it was the same for any upgrade path. I can't remember if it needed to be specifically in tainted updates or whether just any updates was sufficient.

It's been so long since this was looked at that I've forgotten now :\

[Thomas Backlund (tmb)]

Any media flagged as update media is sufficient.

[J-manuel (j-manuel)]

Any chance to fix this bug for mga 2 ?

[Thierry-vignaud (thierry-vignaud)]

No

[4-alien (4-alien)]

can we put this on mga3 tracker?

[Eeeemail (eeeemail)]

This has been worked around by QA so far.

QA will already have double the workload when mga2 is released, so delaying to mga3 is not really an ideal outcome.

[Guillomovitch-4 (guillomovitch-4)]

Unfortunatly, without any manpower to fix it in the first place, that's worthless to keep it as release blocker. Changing its priority to high.

[Eeeemail (eeeemail)]

The manpower hardly exists in QA to continue to workaround it across two releases either! The workload will already be doubled simply because there are now two releases with two architectures to perform QA upon. Mistakes are bound to happen.

This was first reported in July last year. If it is a 'Wontfix' then it should be closed as such.

A new scenario for this bug has been found to be when doing updates during an installation. It fails on packages due to recursive deps of added suggests. The added suggest cannot be installed. See bug 3545.

[Sander Lepik (sander85)]

I don't think that update should install new suggested packages at all. It should update packages that you already have + install required packages.

[Thierry-vignaud (thierry-vignaud)]

Neither are either the right behavior or the current behavior of urpmi and the like.
The right (and current) behavior is to install only new suggests on update.

Suggests that were already in the previous release of the package but that were
not installed will remains not installed.
But the suggests that got newly added in the new release of the package will get installed.

[Andre999mga (andre999mga)]

It seems to me that the right behavior for suggests would be
1) Install all suggests already installed, as presumably the user accepted installing them, and

2) Otherwise treat the "suggests" as suggestions,
i.e. ask the user if they want to install each suggest.

I would favour presenting a list of all the suggests together, with name of the package suggesting each, and preferably a one-line comment indicating what each suggest provides.
Then let the user decide for each, "yes", "no", or "ask me later".
The latter would be saved to be asked automatically on subsequent updates.

This would probably involve some work to implement, but I think that this is the "right way" to treat suggests.

[Eeeemail (eeeemail)]

Created attachment 2432
Current QA depcheck script

This is the current script we have, which takes into account deps of added suggests.

[4-alien (4-alien)]

some progress info:

1. i've already got the patch that only adds full repositories (not updates only)
2. MageiaUpdate part, i've been looking around, doing some debugging, but i can't quite get to the point where it's supposed to be, especially since it states to use searchmedia...
3. i'm gonna start at urpmi --update next, and skip MageiaUpdate, until i've got this one. likely the code could be similar so, i'll detect it hopefully better where it needs the change.

still, i've spent a few hours for a couple of days on this. if anyone who knows this code can help me point to something, you'd be very welcome...

[Eeeemail (eeeemail)]

It's very much appreciated AL13N.

[4-alien (4-alien)]

though that may be, we don't have results yet

[4-alien (4-alien)]

I guess "yet" was the keyword there...

[4-alien (4-alien)]

Created attachment 2466
rpmdrake-only-full-sources.patch

this patch will disable adding only partial updates, it's not supported anyway.

the other day, i've seen yet another person having this issue.

in the comments, it appears this was absolutely a condition before we could make --update behave like --searchmedia .

[4-alien (4-alien)]

i'll try to put a detailed list of what i think is happening and how it should be fixed:

the fix should be in the perl urpm/*.pm somewhere.

IIUC, this is what happens now (wrt updates):

1. at some point media is being evaluated:
2. all active media are marked as searchmedia
3. later in the code, (only for updates), i think some kind of ignore function is called for all media that isn't marked as update.

i think the fix should be in the part that decides for which media to call this ignore function.

specifically, an option in the media.cfg is loaded in a distribconf object (updates_for). this option is only set for update media (normally). the idea is that the following:

for each media (in that loop that would ignore a media for searching), check if that media is mentioned in one of the update media in the updates_for function. if it's in there, then don't call that ignore.

i hope someone can fix this one sooner rather than later though

[Boklm (boklm)]

(In reply to comment #41)
> The problem with this change is it will use any activated media, including
> third party media and backports. This is too risky. The need is not for updates
> to pull dependencies from anywhere, only from release media.
>
> Sorry to kill hopes :)

If people don't want to install packages from a media, then they should not activate that media.

The patch from #c40 seems correct to me. Before the patch, MageiaUpdate :
- tag as searchmedia all update media
- load synthesis from update media only
- use searchmedia medias to find update candidates
- resolve dependencies for update candidates using all loaded synthesis

What the patch change is that synthesis from all active media are loaded, instead of only update ones. So it still uses only medias tagged as update to find update candidates for installed packages, but pull new dependencies from any active media. It treats updates media like --search-media.

If you have a third party or backports media but don't want to install packages from this media, why is it activated ? If the media is active, you should expect that some dependencies can be pulled from this media, otherwise what is the meaning of an active media ?

And that's also how urpmi works. If you urpmi some package, it will pull dependencies from any active media. And nobody complains about unwanted dependencies installed from third party or backports media in that case.

For backports users, there is currently two possibilities to configure backports :
- you want to install all available backports. In that case, you activate backport medias, and tag them as update.
- you don't want to install all available backports but want to cherry pick some of them only. In that case, you keep backport medias as disabled, and install backports using urpmi --searchmedia 'backport medias' or rpmdrake which support installing backports from disabled medias.

MageiaUpdate could be patched to use only medias listed as "updates_for" in media.cfg, but that seems wrong :
- this info is only available in media.cfg, and not everybody is using media.cfg to add their medias
- depending on infos only available in media.cfg is not really clean, if we're using this info, I think we should add it to urpmi.cfg. And this cannot be added easily in an update, as it would require that people remove and add again all their medias.
- if we're handling dependencies between medias, we should do it correctly, and everywhere, not only in MageiaUpdate. And this requires important changes, not really appropriate for an update to a stable release
- we have some infos about media dependencies with "updates_for", but we don't have all the dependencies infos. For instance we don't know that nonfree depends on core medias. Before starting to implement media dependencies we should properly define keyword used in media configuration and what they mean.
- urpmi is already complexe, and we should avoid adding useless complexity. And I don't think media dependencies is really useful.

By the way support for backports in rpmdrake could be improved and cleaned, as it is currently using hardcoded media names to detect medias. For Mageia 3, a backport keyword c...

[4-alien (4-alien)]

(In reply to comment #67)
> (In reply to comment #41)
> > The problem with this change is it will use any activated media, including
> > third party media and backports. This is too risky. The need is not for updates
> > to pull dependencies from anywhere, only from release media.
> >
> > Sorry to kill hopes :)
>
> If people don't want to install packages from a media, then they should not
> activate that media.
>
> The patch from #c40 seems correct to me. Before the patch, MageiaUpdate :
> - tag as searchmedia all update media
> - load synthesis from update media only
> - use searchmedia medias to find update candidates
> - resolve dependencies for update candidates using all loaded synthesis

[...]

> MageiaUpdate could be patched to use only medias listed as "updates_for" in
> media.cfg, but that seems wrong :
> - this info is only available in media.cfg, and not everybody is using
> media.cfg to add their medias

This i didn't know... and that sort of changes things, it even increases the complexity by a whole lot.

Lastly, since we need to have stricter requires anyway, even for backports this patch shouldn't be a problem.

I would prefer this patch to be applied soon-ish, so that it actually fixes bug 2317. it's a simple fix, so there's less stuff that can go wrong. and so we can actually also apply it for our stable releases... thereby lessening the burden of QA team, which is the whole reason of this bug anyway.

[Andre999mga (andre999mga)]

Thinking of comment 68, I could make an interim patch which only adds core/release and core/updates repos to update-tagged repos for updates.

@Claire & QA team :
This is not a complete solution, since it wouldn't entirely take care of nonfree and tainted. This still would mean that dependancies for nonfree in nonfree/release and nonfree/updates would still have to be linked.
Similarly for tainted.
However linking for dependancies in core/release and core/updates would no longer be necessary (for any package).

I'm not sure, but this interim solution could already be essentially ready. (i.e, 2-minute change + preliminary testing.)

So, would you like me to do that ?

[Boklm (boklm)]

(In reply to comment #69)
> Thinking of comment 68, I could make an interim patch which only adds
> core/release and core/updates repos to update-tagged repos for updates.

Hardcoding media names is ugly. And core/release should not be tagged as update, but only used for dependencies. And there is no reason to only use those medias when there are other active medias. So I can't see any good reason for doing this.

We already have a very simple patch to use all active medias for dependencies, and I don't see any reason not to use it.

[Sander Lepik (sander85)]

(In reply to comment #70)
> We already have a very simple patch to use all active medias for dependencies,
> and I don't see any reason not to use it.

Can't we then just patch the thing and end the misery for QA? Almost any solution is better than the current one..

[Nicolas-lecureuil (nicolas-lecureuil)]

hi,

i think we should use what Nicolas Vigier tells and close this bugreport. I think that this is the best way/idea.

[Andre999mga (andre999mga)]

(In reply to comment #70)
> (In reply to comment #69)
> > Thinking of comment 68, I could make an interim patch which only adds
> > core/release and core/updates repos to update-tagged repos for updates.
>
> Hardcoding media names is ugly.

Actually it was media paths, required on all the mirrors.
( in fact, media/core/release and media/core/updates )
Can you think of any other way of determining release and update media ?
Pensée magique doesn't work.

> And core/release should not be tagged as
> update, but only used for dependencies.

What I meant to say is adding to active media. My fingers were temporarily disengaged from my brain :-P

> And there is no reason to only use
> those medias when there are other active medias.

That is not at all what I proposed.
Don't forget policy is that updates should use release and update media for dependancies. So what is the problem with adding such media ?

> So I can't see any good reason for doing this.
>
> We already have a very simple patch to use all active medias for dependencies,
> and I don't see any reason not to use it.

Of course, the simple patch would allow a core package with nonfree dependancies, for example.
Would that help QA catch such errors ?
Or a core package with tainted dependancies.
Or a tainted package with nonfree dependancies, etc.

I was just trying to suggest an option that would help QA short-term without opening any loop-holes.

BTW, I'm not sure that we really should accept just any active media for update dependancies, instead of only the official mageia release and update medias.
Since if QA testers have other active media during testing, errors in dependancies could be ignored.
However if we decide to make this restriction, then local repos would have to have the same terminating directory structure to be used.
But the restriction isn't necessary if QA is always careful to ensure that no other media are active. (Or only those limited to packages in official media.)

But when it comes to backports, most testing will be done by non-QA users, where such a restriction would be useful.

[Ennael1 (ennael1)]

Can we keep rather ML for discussions?

[Boklm (boklm)]

(In reply to comment #73)
>
> Of course, the simple patch would allow a core package with nonfree
> dependancies, for example.
> Would that help QA catch such errors ?
> Or a core package with tainted dependancies.
> Or a tainted package with nonfree dependancies, etc.
>
> I was just trying to suggest an option that would help QA short-term without
> opening any loop-holes.

It looks like a contest for most stupid reason to avoid fixing this bug. First one was that users who enabled backports media although they don't want backports can have backports installed. Now this one is that keeping this bug unfixed can help QA catch dependency problems ?

The goal of MageiaUpdate is not doing QA on package dependencies. If QA team want to check that core packages don't have dependencies on nonfree or tainted packages they could write a simple script to check this, and it would be more reliable than relying on a bug in MageiaUpdate which only happens for packages not already installed. Or it could be integrated in build system or youri-check to automatically list such packages. I think youri-check is already checking this.

[Sander Lepik (sander85)]

Who can apply this patch? We are having way too much trouble for QA thanks to this stupid bug. It can't get much worse..

[4-alien (4-alien)]

i don't think comitting the patch is the biggest issue here...

there were some people who originally were against, so i'd like them to re-evaluate their opinion on it.

@pterjan, @tmb, @stormi : Do you agree with boklm Y/N?

[Stormi (stormi)]

(In reply to comment #77)
> there were some people who originally were against, so i'd like them to
> re-evaluate their opinion on it.
>
> @pterjan, @tmb, @stormi : Do you agree with boklm Y/N?

I prepared a comment to reply to the "contest for most stupid reason to avoid fixing this bug" phrase (and the following sentence, which makes a caricature of one's argument) because it hurt, but thankfully yours collided with it so it will remain private between me and me.

If a proper, side-effect-free patch is out of our reach, then I'd prefer us to give the update flag to release media and not change urpmi's behaviour. Now that's only my opinion.

[Boklm (boklm)]

(In reply to comment #78)
>
> If a proper, side-effect-free patch is out of our reach, then I'd prefer us to
> give the update flag to release media and not change urpmi's behaviour. Now
> that's only my opinion.

Which side-effect ? Correct fix is to use all active medias to pull dependencies, the same medias that are used to pull dependencies by rpmdrake or urpmi when installing new packages. There is no reason to workaround this by flagging release medias as update. Especially when workaround is more difficult to apply than correct fix.

[Thomas Backlund (tmb)]

No it's not, letting backports satisfy updates is opening up for a complete mess...

- it means it will pull package combos that QA is not testing -> support is down to YMMW...

- packages would need to have even stricte requires for it to work... currently most packages has Requires >= EVR to support upgrades easily. wich means packages should switch to only "=" or ">=" and "<=" to make sure the correct deps comes in... and in order for that to be really working, someone should test that too...

As for the thing about "if they have the media enabled, they want it" is not really true either...

- if you enable backports because you want spme specific package(s), and MageiaUpdate runs before you disable the media again, it will liste new updates to install, and the enduser wont see that they are coming from the backports media.

[Boklm (boklm)]

(In reply to comment #80)
> No it's not, letting backports satisfy updates is opening up for a complete
> mess...

The patch does not let backports satisfy updates. This would only happen if you have backports as an active media. But there is no reason to enable backport medias if you don't want all backports, you can keep backports media disabled and still install selected backports, using rpmdrake or urpmi --seachmedia. There is no reason to enable backports media if you don't want all backports.

>
> - it means it will pull package combos that QA is not testing -> support is
> down to YMMW...
>
> - packages would need to have even stricte requires for it to work...
> currently most packages has Requires >= EVR to support upgrades easily. wich
> means packages should switch to only "=" or ">=" and "<=" to make sure the
> correct deps comes in... and in order for that to be really working, someone
> should test that too...
>
>
> As for the thing about "if they have the media enabled, they want it" is not
> really true either...
>
> - if you enable backports because you want spme specific package(s), and
> MageiaUpdate runs before you disable the media again, it will liste new updates
> to install, and the enduser wont see that they are coming from the backports
> media.

You should not enable backports media if only installing specific backports. If you do this you will not only have this problem with MageiaUpdate but also with rpmdrake or urpmi which are already pulling dependencies from all active medias.

[Thomas Backlund (tmb)]

(In reply to comment #81)
>
> You should not enable backports media if only installing specific backports. If
> you do this you will not only have this problem with MageiaUpdate but also with
> rpmdrake or urpmi which are already pulling dependencies from all active
> medias.

Um,

One of the specifications we made for backports i that we _will_ support cherrypicking....

[Boklm (boklm)]

(In reply to comment #82)
> (In reply to comment #81)
> >
> > You should not enable backports media if only installing specific backports. If
> > you do this you will not only have this problem with MageiaUpdate but also with
> > rpmdrake or urpmi which are already pulling dependencies from all active
> > medias.
>
> Um,
>
> One of the specifications we made for backports i that we _will_ support
> cherrypicking....

And cherrypicking backports is supported. What is the problem with cherrypicking ?

[Ennael1 (ennael1)]

Please see now http://meetbot.mageia.org/mageia-meeting/2012/mageia-meeting.2012-07-23-19.07.log.html

to sum up

- update MageiaUpdate to pull deps from all active medias
- add warning when enabling backports media
- add disabled backport medias is the "update media" menu in rpmdrake so they can be updated easily even when disabled
- later: add support for backports keyword in urpmi.cfg and media.cfg to flag backports medias, and automatically update hdlists for backports

QA will work on testing at least 3 first items coming soon. Please use mailing-list for any comments now to keep this bug report for coming testings

[Boklm (boklm)]

A wiki page has been created to list the planned changes, and testing procedure :
https://wiki.mageia.org/en/MageiaUpdate_2317

[Davidwhodgins (davidwhodgins)]

Created attachment 2836
depcheck script for finding rpm packages needing linking.

Modified depcheck script. Changes include ...
- exclude packages required by the kernel
- only get the list of base packages if it isn't
already available in /home/$USER/.depcheck, since
it shouldn't change after a release.
- use /dev/shm for working directory, for speedup.

[Eeeemail (eeeemail)]

raising priority to appear in blockers list

See council & dev meetings.

[4-alien (4-alien)]

cc'ng derek, maybe he can help

[Derekjenn (derekjenn)]

(In reply to comment #88)
> cc'ng derek, maybe he can help

Not sure how I can help other than to give my opinion which is I think we should immediately commit the patch from comment 40 on the grounds that it makes the GUI behave the same as the command line. No one complains about the command line using inappropriate media.
Nicolas expresses it well in comment 67

In response to tmb's concern about mgaupdate running while back ports is enabled I suggest that could be addressed by testing if any package to be installed comes from backports or 3rd party, and if so displaying a pop up on the lines of "You have backports/3rd party media enabled. You should disable this media if you do not want it to be used to satisfy updates."

Only a minority of users will be using back ports, and they are also likely to be more experienced users. If they choose to ignore the warning it is their problem.

[4-alien (4-alien)]

i thought the wiki page was linked into the bugreport, but it wasn't.

it was decided in a council meeting iirc, that there needed to be additional patches, this is detailed on the wiki page.

@Derek, considering your help on bug 65, i figured that perhaps you could also help here making such patches as are still required. (mostly point 1 or 2 detailed below).

Specifically atm:

1. a patch in the code that does: 'In the Media Manager gui, the option to enable a backport media should display a warning'
2. a patch that makes '"update media" menu in rpmdrake' also update backports and not only updates.
3. adding README.update.urpmi file will be added to notify users of the change (trivial)

this bug has been bugging us for far too long, it's time it got fixed once and for all.

[Manuel-mageia (manuel-mageia)]

alien read that please: http://meetbot.mageia.org/mageia-meeting/2013/mageia-meeting.2013-01-07-20.10.log.html#l-349

[Thierry-vignaud (thierry-vignaud)]

Actually, the issue is fix for bug #1024 which disabled looking for deps in other media (which we had since Christophe Fergeau fixed mdv#51268 on 2010-04-23)

The root cause for the issue in bug #1024 was fixed in media.cfg so we could:
1) revert that change
2) make urpm::select/media abort early when using --update w/o update media

[4-alien (4-alien)]

ah ic...

what if we do both? that way no update media would still abort, and thus give the message no update media defined AND have 2317 fixed for it's dependencies.

of course, this is assuming urpm::select/media is ran only for the real request and not for it's dependencies

[Thierry-vignaud (thierry-vignaud)]

BTW you can test by backporting http://svnweb.mageia.org/soft/rpm/urpmi/trunk/urpm/media.pm?r1=7569&r2=7568&pathrev=7569

eg download http://svnweb.mageia.org/soft/rpm/urpmi/trunk/urpm/media.pm?view=patch&r1=7569&r2=7568&pathrev=7569

then as root, in a terminal run:
cd /usr/lib/perl5/vendor_perl/5.16.2/
patch -p3 < /where/it/was/downloaded/the_name_you_used_for_the_dl

[4-alien (4-alien)]

if we revert #1024...

what about that original issue, is it problematic if you have no update media?

like DVD media or something?

[Ennael1 (ennael1)]

Can we sum up here the status of this bug? What tests, how to close it?

[Thierry-vignaud (thierry-vignaud)]

media.cfg has been fixed long ago, so we don't care about #1024
mgaupdate/urpmi are fixed on mga3 (aka #1024's fix has been reverted) but
I'm looking for more testing by other people.
eg: applying the above patch on mga2 and confirming it pulls additionnal deps from core/release

[4-alien (4-alien)]

perhaps it can be put into updates_testing (mga2) and tested by QA team, since they have the most benefit from it?

[4-alien (4-alien)]

shouldn't this be changed from MGA1TOO to MGA2TOO ?

[Davidwhodgins (davidwhodgins)]

(In reply to Thierry Vignaud from comment #94)
> BTW you can test by backporting
> http://svnweb.mageia.org/soft/rpm/urpmi/trunk/urpm/media.
> pm?r1=7569&r2=7568&pathrev=7569
>
> eg download
> http://svnweb.mageia.org/soft/rpm/urpmi/trunk/urpm/media.
> pm?view=patch&r1=7569&r2=7568&pathrev=7569
>
> then as root, in a terminal run:
> cd /usr/lib/perl5/vendor_perl/5.16.2/
> patch -p3 < /where/it/was/downloaded/the_name_you_used_for_the_dl

Had to "cd /usr/lib/perl5/vendor_perl/5.14.2" for Mageia 2.

Disabled update repositories. Installed zoneminder. Uninstalled
perl-Archive-Zip, which only exists in core release. Enabled the updates
repositories, restarted mgaapplet.

It correctly installed the updates, including what would look like a new
requires for perl-Archive-Zip which it pulled in from core release.

So now all we need is a version of urpmi in updates testing, with the patch
applied, for further testing.

[Thierry-vignaud (thierry-vignaud)]

Fixed.

[Eeeemail (eeeemail)]

Does this fix tainted/nonfree updates with added requires/suggests too?

eg. We've seen previously where a tainted updates needs something new in core/release or tainted/release.

[Manuel-mageia (manuel-mageia)]

Does now mgaonline search also in the repositories */updates_testing if it's activate but not checked as 'updates' ? it was not the case previously (I'm on mga2)

[Eeeemail (eeeemail)]

also updates at the end of installation were affected

[Denis Silakov (dsilakov)]

Fixed in upstream this April.