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().
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
(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
CC: (none) => 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.
Priority: Normal => HighSeverity: normal => critical
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
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
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?
(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
CC: (none) => davidwhodginsBlocks: (none) => 2353
Blocks: (none) => 2379
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
err, one email doesn't exactly define a consensus IMHO...
(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 ?
CC: (none) => jquelin
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
CC: (none) => misc
CC: (none) => sysadmin-bugs
Blocks: (none) => 1576
Blocks: (none) => 2444
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.
Blocks: (none) => 2097
*** Bug 2155 has been marked as a duplicate of this bug. ***
CC: (none) => stewbintn
Blocks: (none) => 2579
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.
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) => PATCHSource RPM: urpmi => rpmdrake-5.26.10-1.mga1.src.rpm
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.
Blocks: 2579 => (none)
Blocks: (none) => 1792
CC: (none) => eeeemail
Blocks: (none) => 2668
Blocks: 2668 => (none)
Blocks: 1792 => (none)
Blocks: (none) => 2255
Blocks: 2255 => (none)
Blocks: (none) => 2451
Blocks: (none) => 1709
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
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
Blocks: (none) => 2906
Blocks: (none) => 1673
Blocks: (none) => 1882
Blocks: (none) => 2813
Blocks: (none) => 2820
Blocks: (none) => 2417
hello is the bug 3038 related to this one ?
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.
CC: (none) => andre999mga
Blocks: (none) => 2977
Blocks: (none) => 3601
Blocks: (none) => 3830
Blocks: (none) => 3833
Blocks: (none) => 2196
Blocks: 3833 => (none)
tracked at https://bugs.launchpad.net/rpm/+bug/913230
CC: (none) => n3npq
CC: (none) => alien
Blocks: (none) => 3050
Blocks: (none) => 4208
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?
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 :\
Any media flagged as update media is sufficient.
Blocks: (none) => 3814
Depends on: (none) => 4566
Blocks: (none) => 4566Depends on: 4566 => (none)
Priority: High => release_blocker
Any chance to fix this bug for mga 2 ?
Blocks: (none) => 3545
No
can we put this on mga3 tracker?
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.
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 => HighCC: (none) => guillomovitch
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.
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
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.
CC: eugeni => (none)
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.
Created attachment 2432 [details] Current QA depcheck script This is the current script we have, which takes into account deps of added suggests.
Blocks: (none) => 6024
Blocks: (none) => 6386
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...
It's very much appreciated AL13N.
though that may be, we don't have results yet
I guess "yet" was the keyword there...
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 .
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.
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 :)
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
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.
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).
Blocks: (none) => 6476
Blocks: (none) => 4061
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.
(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.
(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
(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 :)
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.
Blocks: (none) => 6059
Blocks: (none) => 4914
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
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.
/me sighs... it seems it's already too late then. I just give a patch what people want, i just wa
/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.
(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.
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...
(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
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.
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.
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.
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...
(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 :)
CC: guillomovitch => (none)
Blocks: (none) => 6466
Blocks: (none) => 6502
Blocks: 6502 => (none)
Blocks: (none) => 6272
Blocks: (none) => 3099
Blocks: (none) => 6511
Blocks: (none) => 6656
Whiteboard: (none) => MGA1TOOVersion: 1 => 2
Created attachment 2517 [details] Current depcheck
Blocks: (none) => 6073
Blocks: (none) => 6007
Blocks: (none) => 5939
Blocks: (none) => 6623
Blocks: (none) => 6539
Blocks: 6539 => (none)
Created attachment 2524 [details] Another new depcheck
Blocks: 6623 => (none)
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
still valid, yes
Blocks: (none) => 6486
Blocks: (none) => 3032
Blocks: (none) => 6442
Blocks: (none) => 5432
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
(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.
CC: (none) => shlomif
(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.
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 ?
(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.
(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..
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
Blocks: (none) => 6778
Blocks: (none) => 6679
(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.
Can we keep rather ML for discussions?
CC: (none) => ennael1
Blocks: (none) => 6551
Blocks: (none) => 6855
(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.
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..
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?
(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.
(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.
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.
(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.
(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....
(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 ?
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
A wiki page has been created to list the planned changes, and testing procedure : https://wiki.mageia.org/en/MageiaUpdate_2317
Blocks: (none) => 6770
Blocks: (none) => 7011
Blocks: (none) => 5858
Blocks: (none) => 6581
Blocks: (none) => 6082
Blocks: (none) => 7245
Blocks: (none) => 7381
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
Blocks: (none) => 7547
Blocks: (none) => 2501
Blocks: (none) => 7274
Blocks: (none) => 7633
Blocks: (none) => 7316
Blocks: (none) => 8035
Blocks: (none) => 7369
Blocks: (none) => 8236
Blocks: (none) => 8164
Target Milestone: --- => Mageia 3
Blocks: (none) => 8260
Blocks: (none) => 8465
Blocks: 8465 => (none)
raising priority to appear in blockers list See council & dev meetings.
Blocks: (none) => 8307
CC: (none) => marcello.anni
cc'ng derek, maybe he can help
CC: (none) => 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.
URL: (none) => https://wiki.mageia.org/en/MageiaUpdate_2317
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.
alien read that please: http://meetbot.mageia.org/mageia-meeting/2013/mageia-meeting.2013-01-07-20.10.log.html#l-349
Blocks: (none) => 8184
Blocks: (none) => 8973
Blocks: (none) => 8946
Assignee: thierry.vignaud => tmb
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
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
Assignee: tmb => 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
if we revert #1024... what about that original issue, is it problematic if you have no update media? like DVD media or something?
Blocks: (none) => 9402
Can we sum up here the status of this bug? What tests, how to close it?
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
perhaps it can be put into updates_testing (mga2) and tested by QA team, since they have the most benefit from it?
Blocks: (none) => 9593
shouldn't this be changed from MGA1TOO to MGA2TOO ?
Blocks: (none) => 6927
Blocks: (none) => 7568
(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
Fixed.
Status: NEW => RESOLVEDResolution: (none) => FIXED
Blocks: (none) => 9737
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.
Blocks: (none) => 7803
Blocks: (none) => 8530
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)
also updates at the end of installation were affected
CC: boklm => (none)