ncurses abi 5

Tomasz Pala gotar at polanet.pl
Sun Jan 3 14:54:23 CET 2016


On Sun, Jan 03, 2016 at 12:22:23 +0100, Jan Rękorajski wrote:

>> root at glen ~# poldek -i ncurses
[...]
>>          file /usr/share/terminfo/E/Eterm-88color from install of ncurses-6.0-3.x86_64 conflicts with file from package ncurses-
> [...]
> 
> Use compat-ncurses5 for this instead of creating yet another unnecessary
> package.

As a general rule, we should explicitly forbid mixing libraries with
other resources (manuals, binaries, config files, data) as it breaks multilib.
While noarch data can be worked around by using the same versions of
libraries (provided they are available!), the others cannot coexist. For
example, let's do some dumb check:

~: for i in /usr/bin/*; do rpm -qf $i | wc -l | grep -v 1 && echo $i; done

2
/usr/bin/certtool
2
/usr/bin/cleanscore
2
/usr/bin/gnutls-cli
2
/usr/bin/gnutls-cli-debug
2
/usr/bin/gnutls-serv
2
/usr/bin/psktool
2
/usr/bin/sasl-sample-client
2
/usr/bin/sasl-sample-server
2
/usr/bin/slrn
2
/usr/bin/slrnrc-conv
2
/usr/bin/sqlite3
2
/usr/bin/srptool

Some of the above errors origin from missing arch upgrade paths in older
rpm or poldek, e.g. rpm -qf =slrn

slrn-0.9.8.1pl1-2.1.amd64
slrn-0.9.8.1pl1-2.1.x86_64

but others were a direct consequence of me having to install another
library version.

If PLD were a releasable distro with clean upgrade paths, we shouldn't
care (except for compat libraries for 3rd party software). However with
rolling releases sometimes there IS NOT ANY clean upgrade path
available - last year I was stuck with kernel/glibc/rpm5/db I couldn't
cope upgrading any way (and it was the first time I failed and gave up).
Last week I've been upgrading some very old MySQL 5.0 to current one -
we got 5.1 and 5.6, but 5.5 is missing (I've checked in .archive too).
Ended up seeking for some rpms in the depths of the various mirrors.

My point is: this is not 'yet another unnecessary package'; if it were
splitted a long time ago, there would be no need to create
compat-ncurses5 package at all (with the data files removed). All we
neeed is the ability to build a package from given tag, e.g.
auto/th/ncurses-5.9.20150117-4 and have it automatically saved as
%{name}%{version}-EVR. In a perfect world rpmbuild shoud automatically
split package to %{name} and %{name}-libs if that's not already in spec.
Currently we got %{name}-libs, %{name}-lib, libname and as long as it
seems nice to keep original name of the program, I'm getting tired of
using PLD with different library versions (which is not the state I
desire, but sometimes necessary due to other conditions).

Any library might be required as compat (for 3rd party) - wouldn't it be
better if we got this handled without additional burden of creating
separate package, just STBRing from required tag? But unless rpm can
remove any non-library from the resulting rpm, we should have a rule to
not mix them.


PS. *-bash-completion is a perfect example of pointless subpackage.

Another machine:

2
/usr/bin/dumpsexp
2
/usr/bin/hmac256
2
/usr/bin/ipod-read-sysinfo-extended
2
/usr/bin/notify-send
2
/usr/bin/vpxdec
2
/usr/bin/vpxenc

-- 
Tomasz Pala <gotar at pld-linux.org>


More information about the pld-devel-en mailing list