[pacman-dev] implement .so dependencies?

[Florian Pritz]

Hi,

Regarding the current mass rebuilds because of libpng I'd like to
suggest implementing so dependencies again.

There will be no more cases where packages break because of library
updates and as a nice side effect AUR users see what they have to rebuild.
Pacman will treat those dependencies like others so if a user is sure he
wants to update he can use -Sd.
I've also tested if packages with sodeps would slow down pacman
operation, but that's not really the case.

The current patch adds "sodep-$arch-$soFileName" for every .so file
that's owned by a package in the depends array. Files from optdepends
are silently ignored and if no dependency owns the file there will be a
warning.

I've just rebased the old patch onto HEAD, fixed a little bit and tested
it with libjpeg, so it should be fine.

- --
Florian Pritz -- {flo,bluewind}@server-speed.net

[Florian Pritz]

Post by Florian Pritz
Hi,
Regarding the current mass rebuilds because of libpng I'd like to
suggest implementing so dependencies again.

Bump.

I'd really like to get some comments regarding this patch.

[Xavier Chantry]

Post by Florian Pritz

Post by Florian Pritz
Hi,
Regarding the current mass rebuilds because of libpng I'd like to
suggest implementing so dependencies again.

Bump.
I'd really like to get some comments regarding this patch.

Nagy, you complained about libpng/libjpeg rebuilds yesterday.
Are you interested in this ?

[Nagy Gabor]

Post by Xavier Chantry

Post by Florian Pritz

Post by Florian Pritz
Hi,
Regarding the current mass rebuilds because of libpng I'd like to
suggest implementing so dependencies again.

Bump.
I'd really like to get some comments regarding this patch.

Nagy, you complained about libpng/libjpeg rebuilds yesterday.
Are you interested in this ?

Well, I am not good at script programming, so I assume that this patch
is OK. :-) In my opinion, even if ArchLinux doesn't switch to
sodepends/soprovides, it would be useful, if makepkg supported this
feature. (I like this, because pacman doesn't need to be tweaked. ;-)

This is not the competent ML to decide if ArchLinux's repos should use
these flags, personally I have some concerns about db.tar.gz size. (That
needs testing, which requires patched makepkg, too.)

Bye

[Florian Pritz]

Post by Nagy Gabor
This is not the competent ML to decide if ArchLinux's repos should use
these flags, personally I have some concerns about db.tar.gz size. (That
needs testing, which requires patched makepkg, too.)

I've repacked core and the results are quite good:

core.db.tar.gz from 35KB to 40KB
unpacked db from 2.1MB to 2.2MB

[Nagy Gabor]

Post by Florian Pritz

Post by Nagy Gabor
This is not the competent ML to decide if ArchLinux's repos should use
these flags, personally I have some concerns about db.tar.gz size. (That
needs testing, which requires patched makepkg, too.)

core.db.tar.gz from 35KB to 40KB
unpacked db from 2.1MB to 2.2MB

Here is a little explanation for this nice result:

Florian's patch puts a library into sodepends iff the .so file is owned
by one of its _direct_ dependencies (optdepends are omitted). That is
why the "sodepends" array is shorter than expected (by me).

You may say this method is not as safe as it should be, but imho it
is safe enough (if the user doesn't use the -d switch, of course):
For example, yesterday I broke all my gtk2 packages due to my custom
cairo build (I should have rebuild it with recent libpng). With
soprovides/sodepends enabled, pacman would catch the broken
cairo-cleartype->libpng dependency in the firefox->gtk2->cairo->libpng
dependency chain. So in sum, sodepends/soprovides trick is just ensures
that all "normal" dependencies are not broken in .so level neither.

Moreover, due to this feature, distros can introduce
sodepends/soprovides step-by-step (without rebuilding all packages in
the repo), or they can limit this feature to some "critical" packages.

Bye

[Nagy Gabor]

Post by Nagy Gabor

Post by Florian Pritz

Post by Nagy Gabor
This is not the competent ML to decide if ArchLinux's repos should use
these flags, personally I have some concerns about db.tar.gz size. (That
needs testing, which requires patched makepkg, too.)

core.db.tar.gz from 35KB to 40KB
unpacked db from 2.1MB to 2.2MB

Florian's patch puts a library into sodepends iff the .so file is owned
by one of its _direct_ dependencies (optdepends are omitted). That is
why the "sodepends" array is shorter than expected (by me).
You may say this method is not as safe as it should be, but imho it
For example, yesterday I broke all my gtk2 packages due to my custom
cairo build (I should have rebuild it with recent libpng). With
soprovides/sodepends enabled, pacman would catch the broken
cairo-cleartype->libpng dependency in the firefox->gtk2->cairo->libpng
dependency chain. So in sum, sodepends/soprovides trick is just ensures
that all "normal" dependencies are not broken in .so level neither.
Moreover, due to this feature, distros can introduce
sodepends/soprovides step-by-step (without rebuilding all packages in
the repo), or they can limit this feature to some "critical" packages.

Basically, +1 for implementing this to makepkg and use this in
ArchLinux's repos. (Although this ML is not competent ;-)

I can see only one edge case that should be addressed (that's why I'm
writing this e-mail): Dependencies can be satisfied via provision. What
to do then? (That is not handled at all atm.)

Bye

[Allan McRae]

Post by Nagy Gabor

Post by Nagy Gabor

Post by Florian Pritz

Post by Nagy Gabor
This is not the competent ML to decide if ArchLinux's repos should use
these flags, personally I have some concerns about db.tar.gz size. (That
needs testing, which requires patched makepkg, too.)

core.db.tar.gz from 35KB to 40KB
unpacked db from 2.1MB to 2.2MB

Florian's patch puts a library into sodepends iff the .so file is owned
by one of its _direct_ dependencies (optdepends are omitted). That is
why the "sodepends" array is shorter than expected (by me).
You may say this method is not as safe as it should be, but imho it
For example, yesterday I broke all my gtk2 packages due to my custom
cairo build (I should have rebuild it with recent libpng). With
soprovides/sodepends enabled, pacman would catch the broken
cairo-cleartype->libpng dependency in the firefox->gtk2->cairo->libpng
dependency chain. So in sum, sodepends/soprovides trick is just ensures
that all "normal" dependencies are not broken in .so level neither.
Moreover, due to this feature, distros can introduce
sodepends/soprovides step-by-step (without rebuilding all packages in
the repo), or they can limit this feature to some "critical" packages.

Basically, +1 for implementing this to makepkg and use this in
ArchLinux's repos. (Although this ML is not competent ;-)
I can see only one edge case that should be addressed (that's why I'm
writing this e-mail): Dependencies can be satisfied via provision. What
to do then? (That is not handled at all atm.)

I will have a decent look into that patch later, but I still think it is
a bit of a false sense of security.

e.g readline-6.0 and readline-6.1 both provide libreadline.so.6.
However, building bash against readline-6.1 and running against
readline-6.0 results in a non-booting system... (Trust me, I got the
bug reports). If this approach does not work for even one of the most
critical pair of packages on a system, then I do not see what we are
gaining.

Finally, this would prevent proper upgrades to partially complete
rebuilds. That is fine for some users who would like such things, but
the people doing and testing a rebuild would have issues. I upgraded
the libpng/libjpeg rebuild packages while there were still several
packages needing to be rebuilt for my system. With this patch, I would
be required to do an incredibly stupid "pacman -Syud".

Allan

[Thomas Bächler]

Post by Allan McRae
I will have a decent look into that patch later, but I still think it is
a bit of a false sense of security.
e.g readline-6.0 and readline-6.1 both provide libreadline.so.6.
However, building bash against readline-6.1 and running against
readline-6.0 results in a non-booting system... (Trust me, I got the
bug reports). If this approach does not work for even one of the most
critical pair of packages on a system, then I do not see what we are
gaining.

I get the feeling that you are desperately looking for reason to not
implement a feature that is obviously a necesity. It also seems you
haven't understood what the purpose of this feature is.

The SO name guarantees that when you build a binary against readline
6.0, you can use it with any LATER version of readline (e.g. 6.1) until
the SO name changes. It does NOT guarantee that a binary built against
6.1 will work with 6.0, although the SO name is the same!
Dependencies based on SO names will prevent you from upgrading a library
to a version that is too new for the packages that depend on it. It does
not prevent you from upgrading a package while leaving the library at an
old version.

We currently use (upward, >=) versioned dependencies to ensure the
latter case is alright (systems won't break when you upgrade a package
that needs a newer library). However, we do not have a working mechanism
to prevent you from upgrading a library that is too new for a binary
depending on it. Manually introducing downward (<) versioned
dependencies for this is impossible, as you would have to know in
advance with which (future) version of an upstream library the SOname
will change (some packages keep this in sync with the major version
number, but most don't).
In this sense, SOname depends are not meant to replace versioned
dependencies, but to complement them.

Post by Allan McRae
Finally, this would prevent proper upgrades to partially complete
rebuilds. That is fine for some users who would like such things, but
the people doing and testing a rebuild would have issues. I upgraded
the libpng/libjpeg rebuild packages while there were still several
packages needing to be rebuilt for my system. With this patch, I would
be required to do an incredibly stupid "pacman -Syud".

This is a solvable problem - a weaker -d flag could ignore any versioned
dependencies and only take the package names into account. And I guess
implementing such a flag wouldn't be too hard either.

The latter argument again makes me think you are desperately looking for
a reason why this would be a bad idea.

[Pierre Schmitz]

Post by Thomas Bächler
I get the feeling that you are desperately looking for reason to not
implement a feature that is obviously a necesity.

I like the idea of adding sodeps and soprovides. Ideally they should be even
added to the db files so tools could use this information to create a rebuild
list or a global dependency check.

What I really don't like is magically adding them to existing depends and
provide arrays. They should stay in their own arrays. The point where you
added the soname-prefix should have told you that you are probably doing some
kind of evil hack here.

Here are my arguments why adding those sodeps to existing depends is bad; the
idea in general is not:

In addition to Allan's arguments one has to see that theses sodeps just cannot
be 100% safe. And even if they would work for 90% of our packages the left 10%
would possibly break the other due the nature of a dependency tree.

E.g. you are just providing the soname of any file that is included in a
package. But you have no idea if other apps will load this library at runtime
or if the linker does pick it up. For example there are file with the same so
names in different directories (I think I have seen same names in kdelibs3 and
kdelibs). Some apps bring their own version of a lib like jre has its own
libjpeg.

Sure, you could disable soprovides for known "broken" packages. But let's face
it: we will have such packages in our repos that break everything else due to
such false provides and deps; especially if the maintainer does not see what
happens here and has no real control over it.

My suggestion is: implement this as separete sodeps and soprovides arrays
without the soname-prefix and let's write tools to make use of it. And maybe
we could teach pacman using those information, too. E.g. it could issue a
warning if it found a broken sodep.

Pierre

[Thomas Bächler]

Post by Pierre Schmitz

Post by Thomas Bächler
I get the feeling that you are desperately looking for reason to not
implement a feature that is obviously a necesity.

I like the idea of adding sodeps and soprovides. Ideally they should be even
added to the db files so tools could use this information to create a rebuild
list or a global dependency check.
What I really don't like is magically adding them to existing depends and
provide arrays. They should stay in their own arrays. The point where you
added the soname-prefix should have told you that you are probably doing some
kind of evil hack here.

I was thinking about something halfway in the middle of Florian's
approach and yours (maybe not a good idea):

- Always add sodeps to the usual provides array (but only scan certain
directories for libraries, like /lib, /usr/lib and whatever else we put
in ld.so.conf).
- Add an "implicit dependencies" feature, which would extend the
explicit dependencies with sodeps or whatever else we may think of in
the future. Then add a flag to pacman to ignore these implicit dependencies.

Maybe your approach is better and we separate the provides and implicit
provides accordingly.


However, it's worthless to discuss implementation and concepts if the
idea is entirely rejected by our main makepkg developer.

[Allan McRae]

Post by Thomas Bächler
However, it's worthless to discuss implementation and concepts if the
idea is entirely rejected by our main makepkg developer.

It is not entirely rejected. I just have very limited time at the
moment so end up just pointing out what I do not like about ideas. I
actually do like some of the idea, but there are parts I obviously
dislike. In future I'll put some effort into being clearer about that...


Anyway, here are some of my opinions on this idea:

1) I'd prefer just using a single depends array rather than an
additional sodepends array. A version of pacman's "-d" ignoring
dependency versioning would not require a separate array and would be
far more useful than one that ignored sodepends. I think that should be
implemented in pacman no matter what.

2) I do not like "magically" adding libraries to the depends/provides
array. I really want them to be manually specified (versions can be
automatic - see #3). For example, the readline package would want to
provide libreadline.so as that is important but libhistory.so is really
not... What is important or not would be up to the distro packagers.

3) I would like the sodeps to be listed like (e.g) "libreadline.so".
This makes the dependency named closer to what is actually is. Makepkg
could recognize the ".so" at the end and use readelf on the binaries and
automatically add the relevant version. The "soname-arch" type prefix
is ugly. "soname" is covered by the ".so" and multi-lib stuff is not
really as critical so "arch" is not really needed either.

These three points would go a long way to alleviate my concerns about this.

[Thomas Bächler]

Post by Allan McRae
It is not entirely rejected. I just have very limited time at the
moment so end up just pointing out what I do not like about ideas. I
actually do like some of the idea, but there are parts I obviously
dislike. In future I'll put some effort into being clearer about that...

Great to hear that, so we can actually discuss possible
implementation(s) now.

Post by Allan McRae
1) I'd prefer just using a single depends array rather than an
additional sodepends array. A version of pacman's "-d" ignoring
dependency versioning would not require a separate array and would be
far more useful than one that ignored sodepends. I think that should be
implemented in pacman no matter what.
2) I do not like "magically" adding libraries to the depends/provides
array. I really want them to be manually specified (versions can be
automatic - see #3). For example, the readline package would want to
provide libreadline.so as that is important but libhistory.so is really
not... What is important or not would be up to the distro packagers.

I can live with both of those changes.

Post by Allan McRae
3) I would like the sodeps to be listed like (e.g) "libreadline.so".
This makes the dependency named closer to what is actually is. Makepkg
could recognize the ".so" at the end and use readelf on the binaries and
automatically add the relevant version. The "soname-arch" type prefix
is ugly. "soname" is covered by the ".so" and multi-lib stuff is not
really as critical so "arch" is not really needed either.

I disagree in the "arch" part. It might not be as important now, but in
the future it could cause problems if we end up havnig multiple
architecture libraries in one system (and ultimately I want to make that
possible, if I ever get to it). If we could agree on this scheme:

soprovides=(libreadline.so)
would generate
provides=("${provides[@]}" libreadline.so-x86_64=6)

Then the "weak -d" flag could ignore the =6 version above and we still
have everything we would need for matching so-names.

[Florian Pritz]

Post by Thomas Bächler
I disagree in the "arch" part. It might not be as important now, but in
the future it could cause problems if we end up havnig multiple
architecture libraries in one system (and ultimately I want to make that
soprovides=(libreadline.so)
would generate
Then the "weak -d" flag could ignore the =6 version above and we still
have everything we would need for matching so-names.

[Thomas Bächler]

For the arch part a better way to find the arch of the lib would be
nice. Neither readelf nor objdump seem to fit. Readelf only shows 32/64
and objdump shows i686 libs as i368. If anyone has an idea please share.

Technically, i686 is i386, just a restricted flavor. I don't think it's
a problem.

[Allan McRae]

+#-- soprovides:add .so files to provides array
#
-OPTIONS=(strip docs libtool emptydirs zipman purge)
+OPTIONS=(strip docs libtool emptydirs zipman purge soprovides)

Just a small comment on this. Do we really need the new option here? I
think that someone specifying a library so name in the depends/provides
is enough to indicate that they want to do this.

Allan

[Allan McRae]

Post by Thomas Bächler

Post by Allan McRae
3) I would like the sodeps to be listed like (e.g) "libreadline.so".
This makes the dependency named closer to what is actually is. Makepkg
could recognize the ".so" at the end and use readelf on the binaries and
automatically add the relevant version. The "soname-arch" type prefix
is ugly. "soname" is covered by the ".so" and multi-lib stuff is not
really as critical so "arch" is not really needed either.

I disagree in the "arch" part. It might not be as important now, but in
the future it could cause problems if we end up havnig multiple
architecture libraries in one system (and ultimately I want to make that
soprovides=(libreadline.so)
would generate
Then the "weak -d" flag could ignore the =6 version above and we still
have everything we would need for matching so-names.

OK. I will concede the need for the arch part then. But it needs some
changing. As I said before, I would prefer soprovides detected by
ending in ".so" in the provides array and I do not really like entries
in the provides array automatically changing apart from versioning. So...

provides=(foobar libfoo.so)

would result in

provides = foobar
provides = libfoo.so=6-x86_64 (does that order look right...?)

in the .PKGINFO file.

I am fairly sure that pacman can handle two packages providing different
versions of libfoo.so but that needs checked.

A patch that did this would be very acceptable to me.

Allan

[Nezmer]

Post by Allan McRae

Post by Thomas Bächler
I disagree in the "arch" part. It might not be as important now, but in
the future it could cause problems if we end up havnig multiple
architecture libraries in one system (and ultimately I want to make that
soprovides=(libreadline.so)
would generate
Then the "weak -d" flag could ignore the =6 version above and we still
have everything we would need for matching so-names.

OK. I will concede the need for the arch part then. But it needs some
changing. As I said before, I would prefer soprovides detected by ending
in ".so" in the provides array and I do not really like entries in the
provides array automatically changing apart from versioning. So...
provides=(foobar libfoo.so)
would result in
provides = foobar
provides = libfoo.so=6-x86_64 (does that order look right...?)
in the .PKGINFO file.
I am fairly sure that pacman can handle two packages providing different
versions of libfoo.so but that needs checked.
A patch that did this would be very acceptable to me.
Allan

What arch are we talking about here.

I ran into this inconsistency when I used pacman/makepkg in FreeBSD.
makepkg uses CARCH , pacman.conf uses "uname -m" which returns amd64 not
x86_64 on FreeBSD , and If I'm looking at the right patch "readelf -h"
is used here which will return ELF32 in 32bin-* and 32lib-* packages and
that is technically correct and an intended behaviour (I think).

[Florian Pritz]

Post by Nezmer
What arch are we talking about here.
I ran into this inconsistency when I used pacman/makepkg in FreeBSD.
makepkg uses CARCH , pacman.conf uses "uname -m" which returns amd64 not
x86_64 on FreeBSD , and If I'm looking at the right patch "readelf -h"
is used here which will return ELF32 in 32bin-* and 32lib-* packages and
that is technically correct and an intended behaviour (I think).

I'm now using objdump to be able to tell apart ARM and x86 because
readelf returns ELF32 for both, but I can use sort of everything. uname
doesn't help because you could crosscompile 32bit libraries on a 64bit host.

[Allan McRae]

Post by Florian Pritz

Post by Nezmer
What arch are we talking about here.
I ran into this inconsistency when I used pacman/makepkg in FreeBSD.
makepkg uses CARCH , pacman.conf uses "uname -m" which returns amd64 not
x86_64 on FreeBSD , and If I'm looking at the right patch "readelf -h"
is used here which will return ELF32 in 32bin-* and 32lib-* packages and
that is technically correct and an intended behaviour (I think).

I'm now using objdump to be able to tell apart ARM and x86 because
readelf returns ELF32 for both, but I can use sort of everything. uname
doesn't help because you could crosscompile 32bit libraries on a 64bit host.

Who is going to be mixing ARM and x86 binaries on the same system...
cross-compiler libraries maybe? I do not think that is a situation we
really need to worry about.

Allan

[Florian Pritz]

Post by Allan McRae
provides=(foobar libfoo.so)
would result in
provides = foobar
provides = libfoo.so=6-x86_64 (does that order look right...?)
in the .PKGINFO file.
I am fairly sure that pacman can handle two packages providing different
versions of libfoo.so but that needs checked.

I did a quick test and it seems to work.

[Florian Pritz]

Post by Florian Pritz

Post by Allan McRae
provides=(foobar libfoo.so)
would result in
provides = foobar
provides = libfoo.so=6-x86_64 (does that order look right...?)
in the .PKGINFO file.
I am fairly sure that pacman can handle two packages providing different
versions of libfoo.so but that needs checked.

I did a quick test and it seems to work.

The attached two patches should fit.

[Allan McRae]

Post by Florian Pritz

Post by Florian Pritz

Post by Allan McRae
provides=(foobar libfoo.so)
would result in
provides = foobar
provides = libfoo.so=6-x86_64 (does that order look right...?)
in the .PKGINFO file.
I am fairly sure that pacman can handle two packages providing different
versions of libfoo.so but that needs checked.

I did a quick test and it seems to work.

The attached two patches should fit.

I have had a quick look at these today and there are still a couple of
things I would like to address. but they are getting much closer to
what I think they need to be.

I have put them on a "sodeps" branch of my pacman repo so they do not
get lost and they will consistently remind me to take a decent look at
them...

Allan

[Frank Thieme]

Post by Allan McRae
I have had a quick look at these today and there are still a couple of
things I would like to address. but they are getting much closer to
what I think they need to be.
I have put them on a "sodeps" branch of my pacman repo so they do not
get lost and they will consistently remind me to take a decent look at
them...

Any news on this? As you already knows, there was a breakage of KDEmod because
of the openssl update lately, that could have been prevented with soname
dependencies. ;)

Bye...Frank

[Florian Pritz]

Post by Frank Thieme

Post by Allan McRae
I have had a quick look at these today and there are still a couple of
things I would like to address. but they are getting much closer to
what I think they need to be.
I have put them on a "sodeps" branch of my pacman repo so they do not
get lost and they will consistently remind me to take a decent look at
them...

Any news on this? As you already knows, there was a breakage of KDEmod because
of the openssl update lately, that could have been prevented with soname
dependencies. ;)
Bye...Frank

We're working on it :)
See ".so provides/depends patches review" thread on this ML.

[Nagy Gabor]

Post by Allan McRae
1) I'd prefer just using a single depends array rather than an
additional sodepends array. A version of pacman's "-d" ignoring
dependency versioning would not require a separate array and would be
far more useful than one that ignored sodepends. I think that should be
implemented in pacman no matter what.

I don't really like introducing sodepends/soprovides array neither, but
I am not 100% against it neither. I like versioned soprovides/sodepends,
but it looks very hackish. :-)

Post by Allan McRae
2) I do not like "magically" adding libraries to the depends/provides
array. I really want them to be manually specified (versions can be
automatic - see #3). For example, the readline package would want to
provide libreadline.so as that is important but libhistory.so is really
not... What is important or not would be up to the distro packagers.

In order to get this work without pain, the patch requires a slight
modification. If you want to limit soprovides to important .so files,
then the requiredby packages' (so)depends array should be also filled in
manually or with care. It would be packager-friendly to leave this work
to makepkg, and then it should check the (so)provides array
of .so-provider dependency.

This modification is also needed in order to make my earlier statement
true (sorry for my mistake):
"Moreover, due to this feature, distros can introduce
sodepends/soprovides step-by-step (without rebuilding all packages in
the repo), or they can limit this feature to some "critical" packages."

Bye

[Nagy Gabor]

Post by Allan McRae
Finally, this would prevent proper upgrades to partially complete
rebuilds. That is fine for some users who would like such things, but
the people doing and testing a rebuild would have issues. I upgraded
the libpng/libjpeg rebuild packages while there were still several
packages needing to be rebuilt for my system. With this patch, I would
be required to do an incredibly stupid "pacman -Syud".

I can't see any problem here. If you are going to break some
dependencies on your system, pacman should disallow that, like with
"regular" dependencies. This is exactly our goal: To avoid system
breakage with partial updates.

Packagers should know what they are doing... Moreover, I can also
support adding some more sophisticated dependency switches (maybe
hidden from end-users), if needed. (Personally, I don't like that I
can't turn on resolvedeps with -d. Moreover, in many cases it is worth
distinguishing target_pkg->foo broken dependencies from local_pkg->foo
broken [reverse]deps.)

Bye


------------------------------------------------------
SZTE Egyetemi Konyvtar - http://www.bibl.u-szeged.hu
This message was sent using IMP: http://horde.org/imp/

[Xavier Chantry]

Packagers should know what they are doing... Moreover, I can also support
adding some more sophisticated dependency switches (maybe hidden from
end-users), if needed. (Personally, I don't like that I can't turn on
resolvedeps with -d.

I was wondering how bad -Sud was and this is exactly what came to
mind. -d is too extreme as it doesn't resolve dependencies.
If it did resolve dependencies but didnt check for breakages, it could
be a better option.

[Tino Reichardt]

Post by Florian Pritz
The current patch adds "sodep-$arch-$soFileName" for every .so file
that's owned by a package in the depends array. Files from optdepends
are silently ignored and if no dependency owns the file there will be a
warning.
I've just rebased the old patch onto HEAD, fixed a little bit and tested
it with libjpeg, so it should be fine.

I like the idea. It would be VERY nice, if this patch find its way into
pacman :)