Mageia forum

by **jaywalker** » Jan 14th, '12, 18:08

I could be missing something very subtle here, but I have just (1600GMT) declined to to allow a rather huge number of updates to be "updated". Thing is, I spotted a few names at the head of the list which I didn't think I had installed (kde4 stuff, gstreamer) and scanning through the rest of the list I saw more unfamiliar names of applications and libraries,

I spot-checked a few of them (select, wait for the info to download and then look at the "Details" section), but most of them had no entry whatsoever for the "Currently installed version" data.

I speculate that some algorithm is in use which surveys currently installed packages and then chooses "upgrades" based on the notion that I would be better off using these alternatives. On the other hand, maybe there is a _good_ reason for this strange behaviour.

Either way, I am troubled by this. What sort of bug can turn an update service into a sneaky application smuggler?

Richard

by **jaywalker** » Jan 15th, '12, 01:26

Well, that took a while, but I think I understand what went wrong.

My evolving standard setup for Mandriva/Mageia is based on the change from KDE to LXDE which became necessary around the time of Mandriva 2010.0. Nevertheless I still use some favourite KDE apps for which there is no really attractive alternative.

The few which I grabbed first, after installation, are konsole, kcalc, and kdenlive. This resulted in a number of necessary kde libraries and other support files being dragged in, as expected.

Two of these packages are Default-kde4-config and mageia-kde4-config-common and this is how I ended up with an update which wants to install applications and libraries which I don't want/need. A simple process of elimination shows that it is mageia-kde4-config-common which is responsible for pulling in Default-kde4-config which in turn requires all but 3 of the 148 other "updates" and Default-kde4-config which is responsible for pulling in mageia-kde4-config-common and all but 3 of the 148 other "updates". How symmetrical! And how novel!

It is "novel" because this dependency of the two config packages on 145 other KDE libraries and applications does not exist for the installed versions. It is also novel in that it suggests that config files now depend on applications; to me that seems to turn the world upside down. Surely it is applications which are normally thought of as depending on configuration.

Now all I have to do is find a quick simple way to blacklist 147 files and I can then go back to using the update notifier.

Richard

by **juergen_harms** » Jan 25th, '12, 22:46

That is off topic wrt alpha 3. But I read with interest that you run LXDE with KDE applicationis - an approach that I am currently exploring as an alternative to getting rid of KDE (the desktop environment, I dont mind the applications). Apart from your package house-keeping problem, is this an approach you would recommend? - could you say a couple of words on the pros and cons?

Apropos black-listing packages: are you aware of /etc/urpmi/skip.list ? (man urpmi.files)

by **jaywalker** » Jan 26th, '12, 00:07

Hi Juergen, glad to oblige. You already know, I am sure, that appropriate dependencies declared in a KDE application package will usually take care of installing any KDE or Qt libraries needed to run the program. This works fine for all sorts of useful programs. Often the library dependencies are not too much of an overhead and well worth it for the use of the desired program.

Small problems can arise if you want to use programs which are part of KDE as opposed to programs which just use KDE. For example, I like kaffeine for watching DVB-T, even though its KDE4 incarnation still has a long way to go to regain the utility it lost in the migration from KDE3. Adding it now only requires a sqlite library as the other dependencies have already been pulled in by other KDE/Qt programs.

On the other hand, installing a program which is heavily integrated with KDE could result in most of KDE being installed too. In the past I have elected to install the task-kde4-minimal to get the environment for KDE programs - I just don't ever use its desktop.

I've been using the LXDE desktop since Mandriva 2010 (I stayed with 2008 for a few years as it had the best KDE3 desktop ever) and it took a little time to get used to such a spartan (by KDE3 standards) environment. At first I didn't like its file manager so I just continued to use Konqueror (hate Dolphin too). That was a completely satisfactory solution. The LXDE file manager is now a lot better and still improving (though the latest Alpha3 updates seem to have introduced a bug in its removable drive handling). I found it quite nice in its default configuration and it is quite easy to apply the few tweaks I wanted to make it suit me a little better. it also does a good job of keeping the applications menu up to date with installations and removals of programs.

I cannot think of any general argument against the use of KDE/Qt programs with LXDE (or Xfce, or any other window manager/desktop). Indeed, I found that the performance of some of them was greatly improved in LXDE compared to KDE4. It was my discovery that video playback in kaffeine was so much smoother in LXDE that converted me in the first place. Some KDE programs, perhaps, take a little longer to start than you might expect. Kate and konsole, for instance, may take a couple of seconds, but that might be the same under KDE for all I know!

Finally, /etc/urpmi/skip.list. I have my two "avoid at all costs" package names in skip.list. I hope I have done it correctly, but the only way I can know for sure that I made a typo or some more fundamental mistake is if it fails and I get 46 additional files I neither need nor want. That is too big a price to pay in cleanup time. Even if I just shrug and accept it, the slowness of my connection to whatever Mageia mirror I have been given and the continuing requirement to update these unnecessary files is enough to prevent me from testing the effectiveness of skip.list.

The perceived risk is reinforced by the total lack of any obvious indication that the skip.list files will be skipped. The software manager continues to display them in my updates list and continues to advise me of all of the additional non-dependencies which will be installed should I accidentally click yes to everything. The man page doesn't help much in clearing up my doubt either.

man urpmi.files wrote: /etc/urpmi/skip.list
The list of packages that should not be automatically updated when using --auto-select.

That tells me that it is not used when using rpmdrake to install notified updates from a user-confirmed list of packages.

Can you tell I'm getting intolerant and argumentative in my old age?

Richard

by **doktor5000** » Jan 26th, '12, 02:03

jaywalker wrote:Finally, /etc/urpmi/skip.list.
[...]
The perceived risk is reinforced by the total lack of any obvious indication that the skip.list files will be skipped. The software manager continues to display them in my updates list and continues to advise me of all of the additional non-dependencies which will be installed should I accidentally click yes to everything. The man page doesn't help much in clearing up my doubt either.

If done correctly, the packages will not be touched by either urpmi, rpmdrake and not listed in update applet.
Maybe you've used a wrong regular expression? Mind to show your skip.list?

by **jaywalker** » Jan 26th, '12, 02:43

doktor5000 wrote:If done correctly, the packages will not be touched by either urpmi, rpmdrake and not listed in update applet.

That's great. I wouldn't have guessed it from the man page. Maybe it is mentioned in the documentation for those other programs.

Here is my skip list. I didn't try to use "regular" expressions as it wasn't too clear from the example how they are written, so I just cut and pasted from the proposed updates list (seemed the simplest thing to do). In retrospect I should perhaps reduce the list to the two packages which newly "require" these. That would be just the first and the eighty eighth

by **juergen_harms** » Jan 26th, '12, 10:09

Thanks for your extensive reply - I will spend some time in trying whether I can configure (and complement) LXDE to become somewhat less spartiate.

Skip list: I have only used this feature occasionally - not good enough stastistics to declare "it is safe", but it has always worked for me

by **doktor5000** » Jan 26th, '12, 10:36

@jaywalker:

You shouldn't list full package names, but use regular expressions. F.ex. to block all telepathy packages, put the following in skip.list:

Code: Select all: /^telepathy/

This skips every package that begins with "telepathy". For regular expressions you might want to look at http://www.grymoire.com/Unix/Regular.html

by **jaywalker** » Jan 26th, '12, 21:15

Sounds complicated. So I cannot use the package name but I should analyse 147 package names to find common elements which can be described by a number of regular expressions?

It nearly gives the impression you aren't really encouraged to use the skip list. The page you referenced isn't too encouraging either;

On Linux and other UNIX systems, you might find out that some of these features are not implemented. Your milage may vary.

What is the recommended method to test that the expressions in skip.list are valid and will do what is required?

Richard

by **doktor5000** » Jan 26th, '12, 22:16

It's not complicated, it's versatile. Using your expressions, every later version of those packages will not be skipped.
On the other hand, if you want to skip so much packages, that's not a problem of urpmi or skip.list, but it's rather your custom-made problem.

And normally you don't need/want complicated regular expressions in skip.list. Either ^foobar to skip all packages starting
with foobar. Or foobar^ (or $foobar) to skip all packages that have "foobar" anywhere in the name, same applies for version filtering.
IINM the --debug switch to urpmi should tell you which skip-list entries are valid, by telling "skipping some package" or something similar.

by **jaywalker** » Jan 27th, '12, 00:47

doktor5000 wrote:On the other hand, if you want to skip so much packages, that's not a problem of urpmi or skip.list, but it's rather your custom-made problem.

We'll have to agree to disagree on that. I had no part in creating the imagined dependencies for the two packages which cause the additional 145 files to flagged as required. I say the dependencies are imagined because in English a dependency, something on which another depends, implies some form of functional requirement without which the thing which does the depending cannot exist/function/work as intended. In the context of software packaging one may easily imagine that a packaged application may depend on a library which it uses. One would not easily understand why it might depend on a library which it does not use, and still less easily might one understand why an application could possibly depend on some other application, the function, purpose and even existence of which is completely unknown to the user.

In the given case I am using LXDE with a small number of KDE applications which are too useful/familiar to leave out. I expect that when I installed those KDE programs they very reasonably caused the Default-kde4-config and mageia-kde4-config-common packages to be installed as dependencies. After all, some programs need some config. But now the cart has been put before the horse. Now the updated versions of these config packages depend on a small universe of applications and their libraries!

Why do I care? I can assure you it isn't just pure bloody-mindedness. I may be alone in this, but I care about security, economy, efficiency and fitness for purpose. This example of the growing tendency to subvert the main purpose of the rpm dependency impacts on each of these goals.

Security
In another context it would be regarded as a security weakness to tolerate an attack vector which allows programs not chosen by the user to be installed and run. This is what some Mandriva (and now, apparently, Mageia) packagers have done when they have recklessly expanded the definition of what is required to include whatever is convenient for them.

Economy, Efficiency & fitness for purpose
I have elected to use a small, easily transportable external disc drive for Mageia 2. It is exactly big enough for my needs. It can travel with me and provide just what I need wherever I may be. As I cannot always expect to have a high speed internet connection available, or a high speed computer to boot it on, or even a mains electricity supply to power it, it is important to me that I engineer its facilities as carefully as possible to maximise its efficiency. I spend time selecting the tools which I will install to ensure that I have a system which is pleasant to use with the smallest possible footprint on the limited available disc space. This produces further advantages in reducing the bandwidth and time needed for security and other software updates to the minimum.

Causing config files to depend on their applications is just wrong. The real dependency is the other way round. Coincidentally, the real dependency is also more efficient, and more secure (by my definitions). I will probably never convince anyone of this so I must find the tools to allow me to accept this less-than-perfect situation and work around it. It is only my "custom made problem" because I prefer economical, efficient and secure to extravagant, expedient and sloppy.

On a lighter note, I disagree with your implied assertion that urpmi and the skip.list file are not the proper tools for this package management problem of mine. Just because it is awkward and time consuming to set up it doesn't mean that urpmi isn't a great package management tool. I agree that it would be almost perfect if the expertise to create regular expressions for the skip list were included in rpmdrake so that a simple tick in the box would build your list and grey-out the entry for the package in the updates list. It is much easier to tick 147 boxes than write them out by hand.

Richard

by **doktor5000** » Jan 27th, '12, 14:46

jaywalker wrote:
doktor5000 wrote:On the other hand, if you want to skip so much packages, that's not a problem of urpmi or skip.list, but it's rather your custom-made problem.

On a lighter note, I disagree with your implied assertion that urpmi and the skip.list file are not the proper tools for this package management problem of mine. Just because it is awkward and time consuming to set up it doesn't mean that urpmi isn't a great package management tool.

That's your assumption, not mine, and i don't know where my statement, that this is a custom-made problem,
implies that urpmi or rpmdrake are not the proper tools to solve this. The problem doesn't originate in urpmi nor rpmdrake,
it originates in your wish to not install those 147 packages.

Although it would be nice if rpmdrake/urpmi would support "pinning" as in smart (or synaptic, but not used that in a long time)
which would be exactly what you're asking for, but in a normal setup this is mostly not needed, and rarely requested.

by **martinw** » Jan 27th, '12, 22:01

I have to agree with Richard, there's something badly wrong with the package dependencies in cauldron. I've just done a fresh install from the M2 alpha3 DVD, selecting just the LXDE desktop. On running an update, it wanted to install KDE in its entirety. That's surely not right!

I managed to defeat this by removing every KDE related package before doing the update. I think the problem was that the installer had chosen to install kdm (even though it defaulted to gdm) - and that drags in everything else.

by **jaywalker** » Jan 27th, '12, 23:52

I don't think it is a good idea to agree with me. It seems I am wrong.

by **juergen_harms** » Jan 28th, '12, 10:09

Where is the difference between planting a rosebush and digging a hole?

Mageia forum

[SOLVED] Alpha 3 Updates aren't!

[SOLVED] Alpha 3 Updates aren't!

Re: Alpha 3 Updates aren't!

Re: [SOLVED] Alpha 3 Updates aren't!

Re: [SOLVED] Alpha 3 Updates aren't!

Re: [SOLVED] Alpha 3 Updates aren't!

Re: [SOLVED] Alpha 3 Updates aren't!

Re: [SOLVED] Alpha 3 Updates aren't!

Re: [SOLVED] Alpha 3 Updates aren't!

Re: [SOLVED] Alpha 3 Updates aren't!

Re: [SOLVED] Alpha 3 Updates aren't!

Re: [SOLVED] Alpha 3 Updates aren't!

Re: [SOLVED] Alpha 3 Updates aren't!

Re: [SOLVED] Alpha 3 Updates aren't!

Re: [SOLVED] Alpha 3 Updates aren't!

Re: [SOLVED] Alpha 3 Updates aren't!

Who is online