From: rain1@openmailbox.org
To: guix-devel@gnu.org
Subject: About collision encountered arbitrarily choosing ...
Date: Sun, 27 Mar 2016 19:58:15 +0100 [thread overview]
Message-ID: <ee55d4982e86aa7cd1b62562dedebee6@openmailbox.org> (raw)
I was just thinking about the warnings you get after installing
packages:
warning: collision encountered
warning: arbitrarily choosing
because there are a lot of them and they generally don't matter or cause
problems I have learned to ignore them.. but I just spotted this
collision today:
/gnu/store/...-lsh-2.1/share/man/man8/sftp-server.8.gz
/gnu/store/...-openssh-7.2p2/share/man/man8/sftp-server.8.gz
That's only a man page substitution but really any package can shadow
any file with 50% chance (can probably make it 100% by setting up the
hash to come lexically first, not sure).
A bad package could sneakily replace a core system library with, for
example, insecure crypto code. So I think it is something that should be
dealt with.
-------------------------------------------
I had a look at past discussions on this:
* https://lists.gnu.org/archive/html/guix-devel/2015-05/msg00437.html
* https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00106.html
* https://lists.gnu.org/archive/html/guix-devel/2015-09/msg00213.html
* https://lists.gnu.org/archive/html/guix-devel/2015-07/msg00668.html
one idea was a whitelist to reduce the amount of errors displayed.
I've made a list of the collisions I see on my system:
* [gnome] /share/icons/hicolor/icon-theme.cache
* [gnome] /lib/gio/modules/giomodule.cache
* [gnome] /share/glib-2.0/schemas/gschemas.compiled
* [gnome] /bin/gtk-update-icon-cache # because there are 2 versions of
gtk
* [python] /bin/coverage
* [python] /bin/.coverage3-wrap-01
* [python] /bin/py.test-3.4
* [python] /bin/.py.test-wrap-01
* [python] /bin/.py.test-3.4-wrap-01
A suggestion I have for helping reduce this is there could be a post
install phase in gtk build system to delete those specific .cache files.
There could also be a similar one in those python libraries.
Do people agree that this is a potential problem? If so I could attempt
to add such an phase. Or maybe there are other solutions that would
solve this better?
next reply other threads:[~2016-03-27 18:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-27 18:58 rain1 [this message]
2016-03-27 21:30 ` About collision encountered arbitrarily choosing Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ee55d4982e86aa7cd1b62562dedebee6@openmailbox.org \
--to=rain1@openmailbox.org \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).