Bug 2317 - --update option should behave like --search-media <list of the update media>
Summary: --update option should behave like --search-media <list of the update media>
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 2
Hardware: All Linux
Priority: release_blocker critical
Target Milestone: Mageia 3
Assignee: Thierry Vignaud
QA Contact:
URL: https://wiki.mageia.org/en/MageiaUpda...
Whiteboard: MGA2TOO
Keywords: PATCH
: 2155 (view as bug list)
Depends on: 1024
Blocks: 1576 1673 1709 1882 2097 2196 2255 2353 2379 2417 2444 2451 2501 2813 2820 2906 2977 3032 3050 3099 3545 3601 3814 3830 4061 4208 4566 4914 5432 5858 5939 6007 6024 6059 6073 6082 6272 6386 6442 6466 6476 6486 6502 6511 6551 6581 6656 6679 6770 6778 6855 6927 7011 7245 7274 7316 7369 7381 7547 7568 7633 7803 8035 8164 8184 8236 8260 8307 8530 8946 8973 9402 9593 9737
  Show dependency treegraph
 
Reported: 2011-07-28 01:26 CEST by Pascal Terjan
Modified: 2014-05-08 18:06 CEST (History)
19 users (show)

See Also:
Source RPM: rpmdrake-5.26.10-1.mga1.src.rpm
CVE:
Status comment:


Attachments
Current QA depcheck script (9.70 KB, application/octet-stream)
2012-06-06 14:27 CEST, claire robinson
Details
rpmdrake-only-full-sources.patch (2.18 KB, patch)
2012-06-15 23:19 CEST, AL13N
Details | Diff
urpmi-allow-update-to-search.patch (430 bytes, patch)
2012-06-15 23:33 CEST, AL13N
Details | Diff
Current depcheck (9.69 KB, application/octet-stream)
2012-07-02 11:11 CEST, claire robinson
Details
Another new depcheck (9.71 KB, application/octet-stream)
2012-07-05 17:54 CEST, claire robinson
Details
depcheck script for finding rpm packages needing linking. (9.76 KB, text/plain)
2012-09-19 20:00 CEST, Dave Hodgins
Details

Description Pascal Terjan 2011-07-28 01:26:38 CEST
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().
Comment 1 Thierry Vignaud 2011-07-29 06:35:03 CEST
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...

CC: (none) => thierry.vignaud

Comment 2 Thomas Backlund 2011-08-01 10:04:56 CEST
(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.

CC: (none) => tmb

Samuel Verschelde 2011-08-01 10:51:22 CEST

CC: (none) => stormi

Comment 3 Samuel Verschelde 2011-08-01 10:56:48 CEST
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.

Priority: Normal => High
Severity: normal => critical

Comment 4 Eugeni Dodonov 2011-08-06 16:51:25 CEST
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..

CC: (none) => eugeni

Comment 5 Nicolas Vigier 2011-08-07 11:37:20 CEST
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.

CC: (none) => boklm

Comment 6 Thierry Vignaud 2011-08-08 11:59:58 CEST
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?
Comment 7 Thomas Backlund 2011-08-08 13:07:05 CEST
(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.

Hardware: i586 => All

Dave Hodgins 2011-08-15 21:04:27 CEST

CC: (none) => davidwhodgins
Blocks: (none) => 2353

Dave Hodgins 2011-08-17 21:23:49 CEST

Blocks: (none) => 2379

Comment 8 Dave Hodgins 2011-08-18 20:49:32 CEST
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.

Version: Cauldron => 1

Comment 9 Thierry Vignaud 2011-08-19 17:23:37 CEST
err, one email doesn't exactly define a consensus IMHO...
Comment 10 Nicolas Vigier 2011-08-19 17:27:07 CEST
(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 ?
Jerome Quelin 2011-08-22 13:51:35 CEST

CC: (none) => jquelin

Comment 11 Olivier Blin 2011-08-24 23:04:08 CEST
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?

CC: (none) => mageia

Michael Scherer 2011-08-24 23:06:47 CEST

CC: (none) => misc

Manuel Hiebel 2011-08-24 23:09:29 CEST

CC: (none) => sysadmin-bugs

Dave Hodgins 2011-08-25 04:12:58 CEST

Blocks: (none) => 1576

Dave Hodgins 2011-08-25 04:22:12 CEST

Blocks: (none) => 2444

Comment 12 Michael Scherer 2011-08-25 11:17:50 CEST
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.
Dave Hodgins 2011-08-26 05:18:20 CEST

Blocks: (none) => 2097

Comment 13 Stew Benedict 2011-08-28 21:44:48 CEST
*** Bug 2155 has been marked as a duplicate of this bug. ***

CC: (none) => stewbintn

Dave Hodgins 2011-09-01 01:24:21 CEST

Blocks: (none) => 2579

Comment 14 Samuel Verschelde 2011-09-01 10:46:58 CEST
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.
Comment 15 Dave Hodgins 2011-09-01 20:42:29 CEST
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

Keywords: (none) => PATCH
Source RPM: urpmi => rpmdrake-5.26.10-1.mga1.src.rpm

Comment 16 Dave Hodgins 2011-09-02 01:31:18 CEST
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.
Dave Hodgins 2011-09-05 21:07:57 CEST

Blocks: 2579 => (none)

Dave Hodgins 2011-09-06 08:50:01 CEST

Blocks: (none) => 1792

claire robinson 2011-09-06 11:45:56 CEST

CC: (none) => eeeemail

Jani Välimaa 2011-09-08 12:24:19 CEST

Blocks: (none) => 2668

claire robinson 2011-09-08 14:27:14 CEST

Blocks: 2668 => (none)

claire robinson 2011-09-09 15:47:20 CEST

Blocks: 1792 => (none)

claire robinson 2011-09-20 17:50:11 CEST

Blocks: (none) => 2255

Florian Hubold 2011-09-20 18:43:37 CEST

Blocks: 2255 => (none)

claire robinson 2011-09-21 10:50:45 CEST

Blocks: (none) => 2255

Manuel Hiebel 2011-09-25 13:54:19 CEST

Blocks: (none) => 2451

claire robinson 2011-09-28 12:17:44 CEST

Blocks: (none) => 1709

Comment 17 Samuel Verschelde 2011-10-01 03:18:34 CEST
Assigning to maintainer now that our maintainers database has an entry for
this package. Please assign back to bugsquad@mageia.org in case of a mistake
from me.

Assignee: bugsquad => thierry.vignaud

Comment 18 Samuel Verschelde 2011-10-02 22:10:21 CEST
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
Samuel Verschelde 2011-10-02 22:14:24 CEST

Blocks: (none) => 2906

claire robinson 2011-10-07 13:30:15 CEST

Blocks: (none) => 1673

claire robinson 2011-10-08 17:03:40 CEST

Blocks: (none) => 1882

claire robinson 2011-10-08 17:15:59 CEST

Blocks: (none) => 2813

claire robinson 2011-10-09 10:24:00 CEST

Blocks: (none) => 2820

claire robinson 2011-10-13 19:42:25 CEST

Blocks: (none) => 2417

Comment 19 Manuel Hiebel 2011-10-13 22:51:13 CEST
hello is the bug 3038 related to this one ?
Comment 20 claire robinson 2011-10-13 23:27:56 CEST
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.
andré blais 2011-10-21 11:10:59 CEST

CC: (none) => andre999mga

Manuel Hiebel 2011-10-30 01:57:30 CEST

Blocks: (none) => 2977

claire robinson 2011-12-16 11:55:27 CET

Blocks: (none) => 3601

claire robinson 2011-12-28 19:32:09 CET

Blocks: (none) => 3830

claire robinson 2011-12-30 15:34:08 CET

Blocks: (none) => 3833

claire robinson 2011-12-30 15:45:57 CET

Blocks: (none) => 2196

claire robinson 2011-12-30 15:52:28 CET

Blocks: 3833 => (none)

Comment 21 Jeff Johnson 2012-01-07 20:01:23 CET
tracked at https://bugs.launchpad.net/rpm/+bug/913230

CC: (none) => n3npq

AL13N 2012-01-16 14:43:05 CET

CC: (none) => alien

claire robinson 2012-01-22 17:38:29 CET

Blocks: (none) => 3050

claire robinson 2012-01-24 17:44:41 CET

Blocks: (none) => 4208

Comment 22 Dave Hodgins 2012-01-28 04:34:47 CET
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?
Comment 23 claire robinson 2012-01-28 11:32:09 CET
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 :\
Comment 24 Thomas Backlund 2012-01-28 16:52:44 CET
Any media flagged as update media is sufficient.
claire robinson 2012-02-13 14:50:51 CET

Blocks: (none) => 3814

Dave Hodgins 2012-02-19 02:59:01 CET

Depends on: (none) => 4566

claire robinson 2012-02-28 13:16:11 CET

Blocks: (none) => 4566
Depends on: 4566 => (none)

Manuel Hiebel 2012-03-08 02:18:08 CET

Priority: High => release_blocker

Comment 25 Manuel Hiebel 2012-04-25 23:03:30 CEST
Any chance to fix this bug for mga 2 ?
claire robinson 2012-04-30 10:56:22 CEST

Blocks: (none) => 3545

Comment 26 Thierry Vignaud 2012-04-30 11:00:16 CEST
No
Comment 27 AL13N 2012-04-30 11:57:24 CEST
can we put this on mga3 tracker?
Comment 28 claire robinson 2012-04-30 12:05:24 CEST
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.
Comment 29 Guillaume Rousse 2012-05-02 22:16:38 CEST
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.

Priority: release_blocker => High
CC: (none) => guillomovitch

Comment 30 claire robinson 2012-05-03 13:41:35 CEST
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.
Comment 31 Sander Lepik 2012-05-03 14:59:51 CEST
I don't think that update should install new suggested packages at all. It should update packages that you already have + install required packages.

CC: (none) => sander.lepik

Comment 32 Thierry Vignaud 2012-05-03 15:03:11 CEST
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.
Eugeni Dodonov 2012-05-03 17:29:32 CEST

CC: eugeni => (none)

Comment 33 andré blais 2012-05-04 05:16:21 CEST
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.
Comment 34 claire robinson 2012-06-06 14:27:16 CEST
Created attachment 2432 [details]
Current QA depcheck script

This is the current script we have, which takes into account deps of added suggests.
claire robinson 2012-06-11 15:43:44 CEST

Blocks: (none) => 6024

claire robinson 2012-06-15 16:10:42 CEST

Blocks: (none) => 6386

Comment 35 AL13N 2012-06-15 16:41:32 CEST
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...
Comment 36 claire robinson 2012-06-15 17:40:42 CEST
It's very much appreciated AL13N.
Comment 37 AL13N 2012-06-15 20:31:17 CEST
though that may be, we don't have results yet
Comment 38 AL13N 2012-06-15 23:16:18 CEST
I guess "yet" was the keyword there...
Comment 39 AL13N 2012-06-15 23:19:01 CEST
Created attachment 2466 [details]
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 .
Comment 40 AL13N 2012-06-15 23:33:58 CEST
Created attachment 2467 [details]
urpmi-allow-update-to-search.patch

I found it quite odd that all of the code indicated that --update was handled like --searchmedia . i came across this one piece where after all was already marked as --searchmedia, it would yet again filter the media. just ignoring this part seems to do the trick.

What i've done to make sure it works:
1. have urpmi-proxy add 2 repositories (extra release,extra updates)
2. change the null package locally so that it has a number of subpackages
3. have the null package require a package in updates (null in release, the subpackage in updates)
4. have another null subpackage require another subpackages (both in release)
5. install these 4 packages
6. update the null package to require one more subpackage (not installed, but put in release this time) (null is now put in updates)
7. tested urpmi --auto-select (it showed 3 in release and 2 in updates) --> OK
8. tested urpmi --search-media "extra updates" (it showed 1 in release and 2 in updates) --> OK
9. tested urpmi --update --auto-select (it showed 1 in release and 2 in updates as well) --> OK
10. tested MageiaUpdate (it showed 3 package to be updated) --> OK

for me, that means it works. checking speed would not give any usefull information, as it would mean the hdlists could be made alot smaller, (which fetching of is the brute of the slowness for me anyway).

of course, even if it works well, it might not be the best code change or it can be done better.

in any case, i'd like someone to review this almost too simple (but not trivial) one line of code change... (yes, only 1 line was changed)

There, the job is done, i did my part as promised. now it's up to you.
Comment 41 Samuel Verschelde 2012-06-15 23:42:43 CEST
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 :)
Comment 42 Pascal Terjan 2012-06-15 23:46:58 CEST
media.cfg contains needed information (updates_for):

[core/updates]
hdlist=hdlist_core_updates.cz
name=Core Updates
srpms=../../SRPMS/core/updates
media_type=official:free:updates
updates_for=core/release
Comment 43 AL13N 2012-06-16 00:29:25 CEST
actually, i'll state that i don't agree with Stormi on that.

MageiaUpdate updates all activated update repos, and searches deps for all activated repos.

we do test backports, so we just need stricter requires if needed. or even let the backport conflict.

also, if 3rd party repos has update media, it could still be used as well. and i suppose it can pull in deps from either their own release media or our release media.

furthermore, if you have a 3rd party repos, which has a library with extra functionality, you'd want it to be pulled in anyway.


personally, i think this is fine like this. i think whatever people have selected as their repositories, i guess they trust those repositories. and of course, we can't guarantee anything if there's 3rd party repos anyway.
Comment 44 Samuel Verschelde 2012-06-16 00:44:27 CEST
Apart from coding difficulty, I don't see any benefit to pull dependencies from "all activated media" rather than just "release+updates". The latter being 100% safe and effort-free, and the former not (need to tighten the dependencies, need for QA to check for each update that it will not install unwanted versions of deps, not speaking of 3rd party media since you seem to consider normal that an update from Mageia repos pulls dependencies from whatever media contains the highest suitable version/release).
claire robinson 2012-06-16 00:53:09 CEST

Blocks: (none) => 6476

claire robinson 2012-06-16 00:57:55 CEST

Blocks: (none) => 4061

Comment 45 AL13N 2012-06-16 01:11:21 CEST
i think if we limit this, we could make it harder for 3rd party repositories, which, imho would go against our values.

also, i don't think it's 100% safe and effort free at all. especially if you do have enabled backports or 3rd party media.

besides that tightening dependencies is a good idea anyway, for people who run urpmi --auto-update for instance.

and for QA, i think it would be satisfactory if it' can be validated if there's a test for i586 and x86_64; and once with backports fully enabled (no cherry picking) and one with backports disabled. essentially, this can still mean a minimum of 2 tests.

i don't see the added benefit of coding this with the release included for each update media that's activated.

imho, if you enable a media/repository, you trust them, so it should work. otherwise it has no business being activated.
Comment 46 Sander Lepik 2012-06-16 09:00:17 CEST
(In reply to comment #45)
> also, i don't think it's 100% safe and effort free at all. especially if you do
> have enabled backports or 3rd party media.
I don't think this is a good idea. You might enable backports repo but that doesn't mean you expect urpmi to pick extra packages from there during update.
And i also don't think that we should support 3rd party media.
Comment 47 AL13N 2012-06-16 09:18:11 CEST
(In reply to comment #46)
> (In reply to comment #45)
> > also, i don't think it's 100% safe and effort free at all. especially if you do
> > have enabled backports or 3rd party media.
> I don't think this is a good idea. You might enable backports repo but that
> doesn't mean you expect urpmi to pick extra packages from there during update.

and why not?

let's give an example:

let's say that in backports, there's an updated version of php.

it's not unfeasable that there's an update of phpmyadmin, which now suggests/requires php-ldap.

would you want that update to get the php-ldap version of updates? or the one from backports? considering all of your php is from backports?

you'd want the one from backports.

And this is exactly why it should be like this.

> And i also don't think that we should support 3rd party media.

of course
Comment 48 Sander Lepik 2012-06-16 09:30:45 CEST
(In reply to comment #47)
> let's say that in backports, there's an updated version of php.
> 
> it's not unfeasable that there's an update of phpmyadmin, which now
> suggests/requires php-ldap.
> 
> would you want that update to get the php-ldap version of updates? or the one
> from backports? considering all of your php is from backports?
> 
> you'd want the one from backports.
> 
> And this is exactly why it should be like this.
You are looking at it the wrong way. Let's say there is backported php in backports media. Now you get some update that needs some extra deps from php tree and urpmi will pull those deps from backports media. Does user want that? I don't think so. php is bad example, i don't think it's backportable at all but anyway :)
Comment 49 AL13N 2012-06-16 14:40:28 CEST
the user want to have the one that's compatible with all the others he has. for it to be the same version.

if there's any packages that has multiple subpackages, and it's backported, and one of it's subpackages will be added as a new dependency with updates, then you'd have a problem.

this is exactly why we need to have stricter requires in any case. so that this would not happen. if it doesn't work for backported version, it should say so, or backported version should say so.
claire robinson 2012-06-17 00:17:03 CEST

Blocks: (none) => 6059

claire robinson 2012-06-19 18:58:12 CEST

Blocks: (none) => 4914

Comment 50 AL13N 2012-06-19 20:25:10 CEST
i know i'm likely impatient, but can anyone comment on my thoughts?

I wonder if you agree with me now, and thus not react, or if you don't agree with me, but don't want to react?

In any case, i can only conclude that if noone complains, then it's good.

Since i'm likely too impatient and don't give people time to react, i'll wait another few days before committing
Comment 51 Samuel Verschelde 2012-06-19 20:29:30 CEST
should it become another endless discussion, I think you can't take such a decision alone in a bug report. You're not just "fixing" a bug, you're changing the meaning of the update applet, this requires more than some comments.
Comment 52 AL13N 2012-06-19 20:37:55 CEST
/me sighs...

it seems it's already too late then.

I just give a patch what people want, i just wa
Comment 53 AL13N 2012-06-19 20:40:33 CEST
/me sighs...

it seems it's already too late then.

I just give a patch what people want, I just want to get this over with. and preferably fixed before backports is enabled to give QA a better chance.

stormi, no offense, but i think you're thinking too much on people who cherry-pick backports. and i don't think we can account for everything.

at least with this solution, people who don't know much about this, will not have issues.
Comment 54 Sander Lepik 2012-06-19 20:51:25 CEST
(In reply to comment #51)
> should it become another endless discussion, I think you can't take such a
> decision alone in a bug report. You're not just "fixing" a bug, you're changing
> the meaning of the update applet, this requires more than some comments.

I agree, changes like this must be discussed in dev ml.
Comment 55 Thomas Backlund 2012-06-19 20:57:03 CEST
Patch in #c39 (removing "updates only" option) seems ok, patch (and comments) in #c40 is not.

the update applet must obey the same rules as buildsystem does and what QA is testing or we get a mess of it.

The only medias _always_ available are core/release, core/updates and the media (_testing + release & updates) you submit to:

when submitting to core updates testing:
core/release, core/updates and core/updates_testing is used.

when submitting to nonfree updates testing: 
core/release, core/updates, nonfree/release, nonfree/updates and nonfree/updates_testing is used.

and so on...

so packages in a /updates media can only be satisfied by it's matching /release tree (with the exception that core release & updates will satisfy the parts that are not in nonfree, tainted /release & /updates)


same goes for backports:

a core/backports package deps can only be satisfied by core/release and core/updates and so on...
Comment 56 Thomas Backlund 2012-06-19 20:59:19 CEST
(In reply to comment #55)
> same goes for backports:
> 
> a core/backports package deps can only be satisfied by core/release and
> core/updates and so on...

of course core/backports satisfies deps for backports
Comment 57 andré blais 2012-06-19 21:29:33 CEST
I agree with tmb, stormi, and sander.

The extra changes proposed by al13n would potentially cause more problems than they solve.
Note that generally backports are supposed to be leaf packages (with some exceptions), so that the scenario given should rarely occur, if backport policies (other than this proposed change) are correctly applied.

It is much better to be first discussed on the mailing list.
Comment 58 AL13N 2012-06-19 21:44:39 CEST
tmb, thanks for the clarification.

but this becomes quite a bother:

so, you're saying that backports dependencies should come from:
 - it's release
 - it's update
 - itself
(also core/release and core/updates)

then updates dependencies should come from:
 - it's release (not backports?)

it becomes more problematic if testing is enabled even.

and if we go towards nonfree or tainted, they can be satisified by core/release and core/updates ?

what about nonfree/backports? can it come from core/backports too?


I see your point, but the coding complexity is now completely off the charts.

atm, we can have a list of media where to search for updates, and another set, to search for it's dependencies. (for all packages)

so:
suppose you have:
(core|nonfree|tainted)/(release|updates)

=> if you want updates, checking your rules above, this would be everything enabled.

(btw: cherrypicking is not even an issue, since backports aren't even enabled)

suppose you have:
(core|nonfree|tainted)/(release|updates|backports)

(actually, since backports is enabled and supported, i guess it should check for updates regarding to backports as well; but that's another discussion)

=> this would mean you'd have everything except for backports.

the problem starts if an update is has a new dependency that is not in updates, however it exists in both release and backports.

MageiaUpdate would get the one from release, which could be incompatible with the other (installed) packages from backports.

Strict requires would not even help, it will NOT get the one from backports, even though you have backports enabled.

How should this be solved in this case?

I have no idea... 

my gut tells me that strict requires would be ideal for the user who uses "urpmi --auto-select" ; thus i think we should do the same for the people who don't know anything about this, and trust us.


In any case, if people think we need to do this in -dev ML. i guess i can understand that. Don't hesitate to mail -dev ML.
Comment 59 Sander Lepik 2012-06-19 22:13:01 CEST
You should not backport packages that are needed for other packages. Simple as that :) If there is update that might need package from backports then the packager who submitted such backport would have to submit updated package into backports repo. So the user could get his/her update from backports repo.
Comment 60 AL13N 2012-06-19 22:27:12 CEST
this is exactly what i mean.

we're talking about a new dependency in an update. so this new dependency could very well be a leaf package before it happend.

and, you can't really put an update in a backport because of that...
Comment 61 andré blais 2012-06-19 23:40:04 CEST
(In reply to comment #60)
> this is exactly what i mean.
> 
> we're talking about a new dependency in an update. so this new dependency could
> very well be a leaf package before it happend.
> 
> and, you can't really put an update in a backport because of that...

If there is a new dependancy for a backport, it indicates likely that there is an important change in the package.  So I think that is it entirely reasonable to require the user to explicitly authorise the update if the new dependancy is also in backports.

Like you say regarding tmb's statement regarding updates, it does get somewhat involved to properly implement.  But by doing in properly, we greatly enhance the reliablility of the update process :)
Guillaume Rousse 2012-06-20 09:28:46 CEST

CC: guillomovitch => (none)

claire robinson 2012-06-20 13:56:59 CEST

Blocks: (none) => 6466

claire robinson 2012-06-20 17:00:28 CEST

Blocks: (none) => 6502

claire robinson 2012-06-21 11:23:16 CEST

Blocks: 6502 => (none)

claire robinson 2012-06-21 12:31:39 CEST

Blocks: (none) => 6502

claire robinson 2012-06-21 16:08:54 CEST

Blocks: (none) => 6272

claire robinson 2012-06-27 15:25:08 CEST

Blocks: (none) => 3099

claire robinson 2012-07-01 23:31:29 CEST

Blocks: (none) => 6511

claire robinson 2012-07-02 11:06:02 CEST

Blocks: (none) => 6656

claire robinson 2012-07-02 11:11:00 CEST

Whiteboard: (none) => MGA1TOO
Version: 1 => 2

Comment 62 claire robinson 2012-07-02 11:11:36 CEST
Created attachment 2517 [details]
Current depcheck
claire robinson 2012-07-02 16:10:21 CEST

Blocks: (none) => 6073

claire robinson 2012-07-03 13:30:10 CEST

Blocks: (none) => 6007

David Walser 2012-07-05 15:09:17 CEST

Blocks: (none) => 5939

claire robinson 2012-07-05 15:57:42 CEST

Blocks: (none) => 6623

claire robinson 2012-07-05 16:23:40 CEST

Blocks: (none) => 6539

claire robinson 2012-07-05 17:53:36 CEST

Blocks: 6539 => (none)

Comment 63 claire robinson 2012-07-05 17:54:45 CEST
Created attachment 2524 [details]
Another new depcheck
claire robinson 2012-07-05 17:56:53 CEST

Blocks: 6623 => (none)

Comment 64 Marja van Waes 2012-07-06 15:05:27 CEST
Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D
Comment 65 claire robinson 2012-07-06 17:06:37 CEST
still valid, yes
claire robinson 2012-07-09 18:23:13 CEST

Blocks: (none) => 6486

claire robinson 2012-07-10 19:00:35 CEST

Blocks: (none) => 3032

claire robinson 2012-07-12 17:06:05 CEST

Blocks: (none) => 6442

claire robinson 2012-07-13 12:19:35 CEST

Blocks: (none) => 5432

Comment 66 AL13N 2012-07-17 19:52:09 CEST
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
Comment 67 Nicolas Vigier 2012-07-18 11:11:47 CEST
(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 could be added to urpmi.cfg to tag backport medias. And then we could add a --backport option to urpmi to install from backport medias. I think that would be much more useful than trying to implement media dependencies.
Shlomi Fish 2012-07-18 19:49:27 CEST

CC: (none) => shlomif

Comment 68 AL13N 2012-07-18 22:51:09 CEST
(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.
Comment 69 andré blais 2012-07-19 04:28:40 CEST
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 ?
Comment 70 Nicolas Vigier 2012-07-19 08:39:49 CEST
(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.
Comment 71 Sander Lepik 2012-07-19 08:56:25 CEST
(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..
Comment 72 Nicolas Lécureuil 2012-07-19 09:09:34 CEST
hi,

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

CC: (none) => nicolas.lecureuil

claire robinson 2012-07-19 12:27:08 CEST

Blocks: (none) => 6778

Dave Hodgins 2012-07-20 03:06:11 CEST

Blocks: (none) => 6679

Comment 73 andré blais 2012-07-20 03:28:33 CEST
(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.
Comment 74 Anne Nicolas 2012-07-20 08:05:19 CEST
Can we keep rather ML for discussions?

CC: (none) => ennael1

claire robinson 2012-07-20 13:46:39 CEST

Blocks: (none) => 6551

claire robinson 2012-07-23 11:48:46 CEST

Blocks: (none) => 6855

Comment 75 Nicolas Vigier 2012-07-23 19:18:09 CEST
(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.
Comment 76 Sander Lepik 2012-07-23 19:22:15 CEST
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..
Comment 77 AL13N 2012-07-23 19:36:16 CEST
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?
Comment 78 Samuel Verschelde 2012-07-23 19:43:01 CEST
(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.
Comment 79 Nicolas Vigier 2012-07-23 20:26:43 CEST
(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.
Comment 80 Thomas Backlund 2012-07-23 21:02:15 CEST
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.
Comment 81 Nicolas Vigier 2012-07-23 21:39:12 CEST
(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.
Comment 82 Thomas Backlund 2012-07-23 21:44:32 CEST
(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....
Comment 83 Nicolas Vigier 2012-07-23 21:47:32 CEST
(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 ?
Comment 84 Anne Nicolas 2012-07-23 23:21:57 CEST
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
Comment 85 Nicolas Vigier 2012-07-23 23:43:31 CEST
A wiki page has been created to list the planned changes, and testing procedure :
https://wiki.mageia.org/en/MageiaUpdate_2317
claire robinson 2012-08-01 18:59:49 CEST

Blocks: (none) => 6770

John Balcaen 2012-08-11 01:36:45 CEST

Blocks: (none) => 7011

claire robinson 2012-08-30 10:05:52 CEST

Blocks: (none) => 5858

claire robinson 2012-08-30 10:06:27 CEST

Blocks: (none) => 6581

Dave Hodgins 2012-08-31 03:58:17 CEST

Blocks: (none) => 6082

claire robinson 2012-09-05 15:13:34 CEST

Blocks: (none) => 7245

claire robinson 2012-09-10 21:54:18 CEST

Blocks: (none) => 7381

Comment 86 Dave Hodgins 2012-09-19 20:00:44 CEST
Created attachment 2836 [details]
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.

Attachment 2524 is obsolete: 0 => 1
Attachment 2517 is obsolete: 0 => 1

claire robinson 2012-09-22 23:45:28 CEST

Blocks: (none) => 7547

Dave Hodgins 2012-09-24 21:02:12 CEST

Blocks: (none) => 2501

claire robinson 2012-09-27 22:11:17 CEST

Blocks: (none) => 7274

Marja van Waes 2012-09-30 12:43:54 CEST

Blocks: (none) => 7633

Dave Hodgins 2012-10-04 22:35:26 CEST

Blocks: (none) => 7316

claire robinson 2012-11-13 15:25:14 CET

Blocks: (none) => 8035

claire robinson 2012-11-29 00:52:52 CET

Blocks: (none) => 7369

claire robinson 2012-11-29 14:29:03 CET

Blocks: (none) => 8236

claire robinson 2012-12-12 01:40:04 CET

Blocks: (none) => 8164

claire robinson 2012-12-12 11:46:33 CET

Target Milestone: --- => Mageia 3

claire robinson 2012-12-15 10:28:09 CET

Blocks: (none) => 8260

claire robinson 2013-01-03 18:11:57 CET

Blocks: (none) => 8465

claire robinson 2013-01-04 15:33:15 CET

Blocks: 8465 => (none)

Comment 87 claire robinson 2013-01-08 21:43:07 CET
raising priority to appear in blockers list

See council & dev meetings.

Priority: High => release_blocker

claire robinson 2013-01-09 17:50:08 CET

Blocks: (none) => 8307

Marcello Anni 2013-01-12 13:06:21 CET

CC: (none) => marcello.anni

Comment 88 AL13N 2013-01-13 08:19:26 CET
cc'ng derek, maybe he can help

CC: (none) => derekjenn

Comment 89 Derek Jennings 2013-01-13 12:55:21 CET
(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.
AL13N 2013-01-13 15:50:49 CET

URL: (none) => https://wiki.mageia.org/en/MageiaUpdate_2317

Comment 90 AL13N 2013-01-13 15:56:32 CET
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.
claire robinson 2013-01-29 10:24:51 CET

Blocks: (none) => 8184

claire robinson 2013-02-07 10:59:54 CET

Blocks: (none) => 8973

Sander Lepik 2013-02-09 10:09:16 CET

Blocks: (none) => 8946

AL13N 2013-03-11 23:01:23 CET

Assignee: thierry.vignaud => tmb

Comment 92 Thierry Vignaud 2013-03-16 06:06:38 CET
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

Depends on: (none) => 1024

Comment 93 AL13N 2013-03-16 08:00:45 CET
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 2013-03-16 08:30:39 CET

Assignee: tmb => thierry.vignaud

Comment 94 Thierry Vignaud 2013-03-16 10:37:54 CET
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
Comment 95 AL13N 2013-03-16 12:31:31 CET
if we revert #1024...

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

like DVD media or something?
claire robinson 2013-03-16 20:00:14 CET

Blocks: (none) => 9402

Comment 96 Anne Nicolas 2013-03-21 09:00:34 CET
Can we sum up here the status of this bug? What tests, how to close it?
Comment 97 Thierry Vignaud 2013-03-24 14:49:04 CET
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
Comment 98 AL13N 2013-03-24 15:01:30 CET
perhaps it can be put into updates_testing (mga2) and tested by QA team, since they have the most benefit from it?
claire robinson 2013-04-05 19:39:58 CEST

Blocks: (none) => 9593

Comment 99 AL13N 2013-04-05 21:07:48 CEST
shouldn't this be changed from MGA1TOO to MGA2TOO ?
claire robinson 2013-04-08 10:01:39 CEST

Blocks: (none) => 6927

claire robinson 2013-04-09 13:28:01 CEST

Blocks: (none) => 7568

Comment 100 Dave Hodgins 2013-04-15 06:37:03 CEST
(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.

Whiteboard: MGA1TOO => MGA2TOO

Comment 101 Thierry Vignaud 2013-04-15 07:52:01 CEST
Fixed.

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

Thierry Vignaud 2013-04-15 07:59:21 CEST

Blocks: (none) => 9737

Comment 102 claire robinson 2013-04-15 10:26:55 CEST
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.
claire robinson 2013-04-25 17:41:21 CEST

Blocks: (none) => 7803

claire robinson 2013-05-07 13:00:09 CEST

Blocks: (none) => 8530

Comment 103 Manuel Hiebel 2013-05-11 11:11:43 CEST
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)
Comment 104 claire robinson 2013-05-11 11:23:03 CEST
also updates at the end of installation were affected
Nicolas Vigier 2014-05-08 18:06:26 CEST

CC: boklm => (none)


Note You need to log in before you can comment on or make changes to this bug.