Permissions

[payasam]

This confuses me, Arctic. I'm on 10.1, and the updater ran when I asked it to run, not before. Do you perhaps mean that the updater only has to be told to get started but not what to do after that, because that it knows or can figure out for itself?

 

I realise this is the wrong place to ask, but why does my "avatar" (a Sanskrit word whose original meaning is something else entirely) not remain what I ask it to be?

Edited December 30, 2004 by payasam

[arctic]

This confuses me, Arctic. I'm on 10.1, and the updater ran when I asked it to run, not before. Do you  perhaps mean that the updater only has to be told to get started but not what to do after that, because that it knows or can figure out for itself?

 

I realise this is the wrong place to ask, but why does my "avatar" (a Sanskrit word whose original meaning is something else entirely) not remain what I ask it to be?

<{POST_SNAPBACK}>

i will try to bring light into the darkness. there are two different things you have to keep in mind. the one thing is that there is an update-checker (the orange icon in the taskbar) that will tell you if official mandrake updates are available. this service is activated by default but needs to be configured prior to usage by clicking the icon and following the instructions. once this is done, it will notify you of new packages and bugfixes/patches.

 

the other thing is updating from additional mirrors (like plf-packages (flash/java/...). these are not included in the mandrake updater. thus you will need to check them on a "regular" basis, like you did before with all packages.

 

when you install mandrake, the basic mirrors for security fixes and patches are set up and can be seen in the mcc, the others need to be set up via easyrupmi first.

 

now when you update your system, the mandrake update will only take care of the official mandrake packages. it starts and does its work and that's it. after that, all bets are off. if you have lots of third party packages added, it is better imho to run urpmi --auto-select because it will solve dependencies with all mirrors. and it will ask you some questions if it should run into trouble. that is why i still prefer running urpmi from the command-line than from a gui or the mdk-update-checker.

 

about your avatar: no idea. ask anon.

[payasam]

I perceive a sputtering candle through dense fog, for which my thanks. As it happens, I too am comfortable at the command line: these window things confuse me. Now I must dash off and look into the easyurpmi business.

[adamw]

MandrakeUpdate is installed by default, but no update source is set up until you first run it, at which point it sets up a source. I don't know exactly how, because I run Cooker so I never *use* MandrakeUpdate :).

 

Let's see if I can break it down a little.

 

Let's imagine a theoretical Mandrake system with no graphical package tools at all. In such a setup all sources, repositories, media (call 'em what you will - 'media' is the official name, but I think it's terrible) are equal. You set them up with the urpmi.addmedia tool, remove them with urpmi.removemedia, install packages from them with urpmi, remove packages with urpme, and query them with urpmq and urpmf. Simple.

 

Now let's bring in the graphical stuff. The "basic" graphical tool is rpmdrake, which is pretty much a graphical version of urpmi and urpme; back in the days of 8.2, it was a single application which could install and remove packages. It uses the same sources and the same package database as the command line tools, they could never be 'out of sync' with each other. Nowadays it's officially two separate apps, rpmdrake and rpmdrake-remove, but same principle. Now imagine a graphical equivalent of addmedia and removemedia - that's urpmi-edit-media (or whatever it's called, I forget). OK, all pretty simple so far.

 

NOW you get MandrakeUpdate, which sort of throws a spanner in the works. What it really *is* is a special-purpose rpmdrake. It does basically the same thing - read a media and install packages from it. But it's specially tweaked for installing security updates to a running system. It will *only* use certain sources - those that are tagged as 'update' sources. The --update parameter to urpmi.addmedia tags a source as an update source on creation. It also won't install new packages; all it does is examine your existing packages and install updates to any for which updates exist in the update medium / media.

 

So it's pretty much a limited special-purpose rpmdrake subset. rpmdrake and urpmi can do *everything* MandrakeUpdate can, plus other stuff it can't, and the three can never be 'out of sync', they're all singing from the same hymnbook so to speak. The panel applet just muddies the water a little further, because what THAT does is periodically check your specified update medium and give you an alert if a package is available. It doesn't install it, you're meant to run MandrakeUpdate to do that.

 

Hope this all helps a bit :)

[payasam]

I see no reason why MandrakeUpdate should not accept sources other than those labelled "update". If such sources could be added manually - or, better, if MandrakeUpdate could be asked to look for them - then just the single tool would do all the work barring the installing, which I don't think should be a problem. This would go, of course, against the general rule that Progress always leads backwards.

[adamw]

You can call any source an 'update' source and have MandrakeUpdate see it, but the current system works best as it gives a single clean and simple update path. I think a distinction between general-purpose and 'updates' sources makes sense, though I'm finding it hard to write down precisely *why*.

[payasam]

The distinction makes sense for the reason that the two serve clearly different purposes. A more logical approach might be to rename MandrakeUpdate to MandrakeSources (or something else) and have two branches in that: one for updates, the other what you call general-purpose.