Mageia forum

Hi,

I've just installed the latest updates for Mageia 3 64bit KDE, that included KDE 4.10.5 and some other things and after update I noticed that it had taken up additional 1.1GB on the root partition. Isn't it too much for a minor update? What could make such a difference, if it is not a glitch?

Thank you.

Where does it take up that additional space?
What does

Code: Select all

du -cmx / --max-depth=1 | sort -rn

or

Code: Select all

du -cmx / --max-depth=2 | sort -rn

show?

Thank you for the reply, doctor.
frankly speaking, I just do not know how to check where exactly that GB is... I only noticed that after installation of 342 packages (and yes, before installation I was notified by MCC that it would download about 300MB and it would take about 1.1GB on the disk) the free size of / shrank for ~1.2GB.
As for thew output, here it is:

Code: Select all

# du -cmx / --max-depth=2 | sort -rn
6794    total
6794    /
5125    /usr
2819    /usr/share
1345    /usr/lib64
883     /opt
709     /var
534     /usr/lib
412     /opt/UCSF
365     /usr/bin
365     /opt/ugene-1.11.3
351     /var/lib
188     /var/log
168     /var/tmp
76      /opt/VMD
44      /usr/sbin
31      /opt/PeaZip
31      /etc
30      /boot
20      /usr/libexec
11      /etc/locale
10      /etc/gconf
4       /var/cache
4       /root
4       /etc/pki
3       /root/drakx
1       /var/yp
1       /var/spool
1       /var/preserve
1       /var/opt
1       /var/nis
1       /var/local
1       /var/empty
1       /var/db
1       /usr/X11R6
1       /usr/src
1       /usr/local
1       /usr/include
1       /usr/games
1       /usr/etc
1       /srv
1       /root/.xauth
1       /root/tmp
1       /root/.local
1       /root/.kde4
1       /root/.dbus
1       /root/.config
1       /root/.chimera
1       /root/.cache
1       /mnt
1       /media
1       /lost+found
1       /initrd
1       /etc/xml
1       /etc/xinetd.d
1       /etc/xdg
1       /etc/X11
1       /etc/virtuoso
1       /etc/vim
1       /etc/urpmi
1       /etc/UPower
1       /etc/udev
1       /etc/tmpfiles.d
1       /etc/texmf
1       /etc/t1lib
1       /etc/systemd
1       /etc/sysctl.d
1       /etc/sysconfig
1       /etc/statetab.d
1       /etc/ssl
1       /etc/ssh
1       /etc/sound
1       /etc/skel
1       /etc/shorewall6
1       /etc/shorewall
1       /etc/sgml
1       /etc/security
1       /etc/sectool
1       /etc/sane.d
1       /etc/samba
1       /etc/rwtab.d
1       /etc/rpm
1       /etc/resolvconf
1       /etc/request-key.d
1       /etc/rc_keymaps
1       /etc/rc.d
1       /etc/pulse
1       /etc/profile.d
1       /etc/prelink.conf.d
1       /etc/ppp
1       /etc/polkit-1
1       /etc/pm
1       /etc/plymouth
1       /etc/pkcs11
1       /etc/pango
1       /etc/pam.d
1       /etc/PackageKit
1       /etc/opt
1       /etc/openldap
1       /etc/openal
1       /etc/obex-data-server
1       /etc/ntp
1       /etc/NetworkManager
1       /etc/netprofile
1       /etc/modules-load.d
1       /etc/modprobe.preload.d
1       /etc/modprobe.d
1       /etc/mirrordir
1       /etc/menu.d
1       /etc/mc
1       /etc/maven
1       /etc/makedev.d
1       /etc/lsb-release.d
1       /etc/logrotate.d
1       /etc/libnl
1       /etc/ld.so.conf.d
1       /etc/jvm-commmon
1       /etc/jvm
1       /etc/.java
1       /etc/java
1       /etc/iproute2
1       /etc/ImageMagick
1       /etc/ifw
1       /etc/ifplugd
1       /etc/hp
1       /etc/gtk-3.0
1       /etc/gtk-2.0
1       /etc/gnome-vfs-2.0
1       /etc/gimp
1       /etc/ggi
1       /etc/gdbinit.d
1       /etc/foomatic
1       /etc/fonts
1       /etc/enscript
1       /etc/emacs
1       /etc/dynamic
1       /etc/dracut.conf.d
1       /etc/dirmngr
1       /etc/depmod.d
1       /etc/default
1       /etc/dbus-1
1       /etc/cupshelpers
1       /etc/cups
1       /etc/cron.yearly
1       /etc/cron.weekly
1       /etc/cron.monthly
1       /etc/cron.hourly
1       /etc/cron.daily
1       /etc/cron.d
1       /etc/cifs-utils
1       /etc/bonobo-activation
1       /etc/blkid
1       /etc/binfmt.d
1       /etc/bash_completion.d
1       /etc/avahi
1       /etc/at-spi2
1       /etc/apparmor.d
1       /etc/alternatives
1       /etc/akonadi
1       /etc/acpi
1       /.dbus/session-bus
1       /.dbus
1       /.config
1       /boot/grub
1       /boot/dracut

What is this command supposed to do? I see that folders in /opt are mentioned in the output - but nothing from there should be touched by the update, as there are programs installed manually from binaries.

It shows you the summed-up size of folders two levels deep starting from / in MB.

You can use something like

Code: Select all

du -m /var | sort -rn | head -25

to e.g. show the 25 biggest folders/files under /var.
Or you could use something like baobab to find big space eaters ...

Huh, I guess I have a suspect - it is texmf-dist (I also remember it took a while to download this package and to install). In /usr/share the folder texmf-dist occupies 1GB (modified today). It contains (apart from others) a huge folder with fonts (>800MB).
For sure, I've never dealt with it before. I have never used TeX and associated software, so I think I do not need it. Looks like it is a glitch and I will try to remove it, since it does not seem to be a dependence for anything.

Hey, hey doktor. I can only partly confirm what zugunder is experiencing, because my situation is even worse: the update has left my x86_64 with a mutant hybrid of KDE 4.10.2 combined with 4.10.5 (some things work, others are now badly broken).

I can confirm zugunder's complaint about the 1.1GiB of extra space. I can't get that far in the update (see below) but right off Software Management's confirmation modal reports: "1GB of additional space will be used; 745MB of packages will be retrieved".

Unlike zugunder, whose update seems to have completed "successfully", I get an Aria2 failure when the updater tries to fetch the 700+MB texlive-texmf-20120701-4.mga3.noarch package.

Stupid me, after it failed and asked if it should attempt to install the other packages anyway I clicked "yes". Many of the new KDE 4.10.5 packages installed, but I think even more failed.

It seems texlive has become a dependency for something as it's not installed at all on my un-updated i686 machine, and I can confirm that zugunder is correct about texlive-texmf-20120701-4.mga3.noarch, it is indeed the package with the 1GB footprint. Since it's a noarch package I don't dare run updates on this box for the certainty that it will also go kaput.

A quick example of what still works on the corrupted machine and what doesn't: Konsole works fine (still 4.10.2) while Gwenview (now 4.10.5) reports "invalid URL" while trying to access any part of the local hdd.

I hope this bit of extra reporting is useful. I also hope I'm getting that Aria2 error, while zugunder didn't, because a diligent team of knowledgeable volunteers are working on the problem right now.

Okay, the Aria2 error seemed to occur because my synthesis files weren't correct (fixed with urpmi.update -a). I can possibly complete the update now, but I'm not especially keen on downloading all 745MB. Un-checking texlive and friends from the update queue doesn't help either (I deselected everything that didn't have a version number of 4.10.5) because it all gets pulled back in as if they've become dependencies.

For the moment I've got a laptop with a broken KDE install. Joy.

Aw crud.

I just found Bug 10388 , and if I'm correctly interpreting what's said there, it appears KDE has indeed become dependant on texlive.

I guess I'll finish the download, and see how things work out.

@zugunder: That bug report seems to answer your initial question. Were you able to successfully uninstall the texlive packages after the fact? If so, do you now have trouble with your PS/PDF/DVI thumbnails in Dolphin and/or Okular)?

artificeprime,

In my case what I found installed on my laptop were texlive-texmf and texlive. I removed them both via MCC (no warnings on dependencies were issued) and everything seems working fine. I made a search on tex among the installed packages and those two I uninstalled seem to be the only related to TeX. So I guess you can do the same.

Good luck!

P.S. After I removed them, I ran update once again - and it was nothing to update, so those two TeX-related packages are indeed something odd and are definitely not necessary.
P.P.S. They say that texlive is necessary for preview of DVI files... big deal However, as I said, I first removed texlive-texmf (no complaints on deps), then texlive (again, no warnings or complaints), so if there are any dependencies, they must have been REALLY soft .
P.P.P.S. I do not have installed kdegraphics4 package, only kdegraphics-strigi-analyzer, -mobipocket and -thumbnailers.

How did those that have this problem install/upgrade?

With a fresh install of Mageia3 using the KDE install DVD upgraded to Mageia4 I do not have texlive-texmf or texlive installed.

Ken-Bergen,

I updated manually via MCC -> Software management -> Update your system.

zugunder wrote:I updated manually via MCC -> Software management -> Update your system.

That's not what I asked.
What was your initial install media and what version, Mageia1, Mageia2 or Mageia3?

Ken-Bergen wrote:What was your initial install media and what version, Mageia1, Mageia2 or Mageia3?

I made a fresh install (no upgrades, clean partitions) of Mageia 3 64bit about a month ago.

zugunder wrote:I made a fresh install (no upgrades, clean partitions) of Mageia 3 64bit about a month ago.

I'm not a dentist so pulling teeth does not come easy.

Again what media, LiveCD, LiveDVD or install DVD?

Ken-Bergen wrote:I'm not a dentist so pulling teeth does not come easy.
Again what media, LiveCD, LiveDVD or install DVD?

It's a DVD, but I am not sure if it is Live or Install, but it contains all available DEs (Gnome, KDE, LXDE, etc), so probably it is Install.

Ken-Bergen wrote:How did those that have this problem install/upgrade?

@Ken-Bergen: Hi, Ken. For my part I'm running MGA3 clean-installed off the MGA3 Dual-Arch CD. No room for ambiguity there, I hope.

To be completely pedantic, MGA3 shipped with KDE 4.10.2, a regular update today updates it to 4.10.5. The problem(s) started because along with KDE's 4.10.5 packages, texlive-20120701-3.mga3.x86_64.rpm, texlive-texmf-20120701-4.mga3.noarch.rpm, perl-Spreadsheet-ParseExcel-0.590.0-2.mga3.noarch.rpm, and lib64zziplib0-0.13.62-2.mga3.x86_64.rpm are getting pulled along as dependencies. This came as quite a surprise to me (and zugunder too, it seems), because texlive and its own dependecies total a 1.1 GiB payload once installed. As stated in my post above, according to Bug 10388, texlive was intentionally added because kdegraphics-thumbnailers-4.10.2-1.mga3 depends on it.

zugunder wrote:I removed them both via MCC (no warnings on dependencies were issued) and everything seems working fine.

See, that's just weird, because it would seem to contradict their necessity as stated in the bug report.

We shouldn't automatically be pulling in an extra 534MB of packages if they're non-essential. Some of us (like me) aren't exactly swimming in bandwidth, and I've got 3 machines to deal with, so I've downloaed the rpms straight off one of the mirrors. I'll install texlive separately on each before doing the update and then remove it after. Thank goodness that 500+MB texmf is noarch. Yeesh, what a headache.

I can only add here my dollar:
50c #1 is that I downloaded the DVD image pretty long ago and since than AFAIK there was an issue (fixed in the next release) with online updates during install. I usually avoid doing that, so I used that old image.
50c #2 - the second result of today's update (in my case) is unstable behavior of several Qt applications like Akregator and Clementine. I use both of them very extensively, so I noticed that unusual behavior immediately. The former has issues with labeling new feeds (many of them appear as "read", but not all; I could not put "important" label on several of them as well). The latter simply froze several times, so that only killing the app could help.
BTW, Clementine is hanging again . Need to restart X or issue a "kill" command...

Just a note that David Walser recommends anyone annoyed by the 1GiB of (non)dependent bloat added to his or her KDE install by texlive-texmf should add their voice to Bug 10673 where a related texlive matter is being addressed.

Instead, you could also use urpmi --auto-update --no-suggests to do the KDE update and you wouldn't have gotten texlife-texmf.

man urpmi wrote: --no-suggests
With this option, urpmi will not install "suggested" packages.
By default, urpmi will install (newly) suggested packages.

doktor5000 wrote:Instead, you could also use urpmi --auto-update --no-suggests to do the KDE update and you wouldn't have gotten texlife-texmf.

Hey thanks doktor, that's awesome. Another option I didn't know existed. I'll store it away for the future.

A question though: how does one know from looking at the update queue in MCC that a package is only being "suggested"?

I'm looking at the queue right now on my i686 box and there is no indication whatsoever in the texlive packages that they're merely suggested. However, for kdegraphics-thumbnailers there is this:

New dependencies:
libfreetype2-1.3.1-42.mga3.tainted.i586
libkpathsea6-20120701-3.mga3.i586
libptexenc1-20120701-3.mga3.i586
...
t1lib-config-5.1.2-14.mga3.i586
texlive-20120701-3.mga3.i586
texlive-texmf-20120701-4.mga3.noarch

So at the very bottom is texlive-texmf appearing very much as if it's become a critical dependency to KDE.

No offence intended, but without some advance warning about incoming suggests, your solution doesn't seem very practical for the average (non-root) user and defeats the point of a user updating via MCC at all. Either you always install suggests or have root fire up a CLI to run this command and never install suggests.

Perhaps MCC should pop up an addition modal in a situation like this? "The following packages are suggested but optional; do you wish to install them? <YES> <NO>" But if there are multiple suggests and a user might want to mix and match them, another window with additional check boxes would be needed, adding more complexity to MCC....

Your command line above is great in this particular case because you know of a suggests after the fact (especially for me since I still have two boxes to update), but its not very practical in a day-to-day use case. Also, in the ~14 years I've been using Mandrake/Mandriva/Mageia a situation like this has never cropped up for me before. Heck, I didn't even know "suggests" packages existed until yesterday, so presumably I've been ignorantly installing them by the dozens all the while.

Anyway, thanks again.

Yes, suggested packages handling via GUI is something that could be improved, much the same as orphans handling.
But for normal desktop usage normally you don't need to care, except if bandwidth or diskspace is really an issue,
but if you care like that, there are ways around this.

For example you could configure your systems easily to not install/ignore suggests by default via /etc/urpmi/urpmi.cfg and then to implicitely allow installing suggests if you want them

man urpmi wrote:
--no-suggests
With this option, urpmi will not install "suggested" packages. By default, urpmi will install (newly) suggested packages.

--allow-suggests
With this option, urpmi will install "suggested" packages. This is useful if you have "no-suggests" in urpmi.cfg.

You may also want to look at https://wiki.mageia.org/en/Feature:SuggestSuggests and https://wiki.mageia.org/en/Removing_packages

doktor5000 wrote:Yes, suggested packages handling via GUI is something that could be improved, much the same as orphans handling.

Very true about the orphans.

doktor5000 wrote:...for normal desktop usage normally you don't need to care...

And given Malo's recent comment in Bug 10673, I hope there's some productive discussion among the packaging/update teams about avoiding this in the future so we desktop users don't have to care (and I can go back to being blissfully ignorant of requires, suggests, and goodness knows what else).

doktor5000 wrote:...you could configure your systems easily to not install/ignore suggests by default...

I imagined as much, but have never directly fiddled with urpmi's settings, nor do I intend to now. I trust in Mageia that it'll get sufficiently sorted.

doktor5000 wrote:You may also want to look at https://wiki.mageia.org/en/Feature:SuggestSuggests and https://wiki.mageia.org/en/Removing_packages

Sure thing. For years I've been compiling an offline, copypasta list of tips and tricks that have saved my butt. There's always room for more.

Thanks again.

doktor5000 wrote:You may also want to look at https://wiki.mageia.org/en/Feature:SuggestSuggests....

I took a look. +1! Yes, this sounds exactly perfect. It's a shame the feature missed the MGA3 target.

I wondered why an update was taking such a long time, and found that the file size of texlive-texmf-20120701-4.mga3.noarch.rpm is over 0.5 Gb. By comparison, the cd version of Mageia 3 is 0.7 Gb.
Why is this update file so big, and why do I need it?

Egg wrote:Why is this update file so big, and why do I need it?

You don't need it:
https://bugs.mageia.org/show_bug.cgi?id=10388#c5

Jim