Opened 22 years ago

Closed 20 years ago

#307 closed defect (fixed)

Fix installation of the same program by more than package

Reported by: gerard@… Owned by: winkie@…
Priority: normal Milestone:
Component: Book Version: CVS
Severity: normal Keywords:
Cc: greg@…

Description

Some packages overwrite files from other packages (we already note this for hostname, but there are a few more). We should mention this so people can take action if they don't want that to happen.

Change History (19)

comment:1 by gimli@…, 22 years ago

After logging a whole by-the-book install with install-log, run this script on the generated logs for a list of duplicates (not guaranteed to work). It doesn't work on checklfs logs though, because they have directory names logged as well.

#!/bin/sh cd $1 && for LOG in *; do

echo "$LOG" for FILE in cat "$LOG"; do

egrep "$FILE" * |egrep -v "$LOG"

done

done

comment:2 by gerard@…, 22 years ago

Priority: normalhighest

comment:3 by gerard@…, 22 years ago

Priority: highesthigh

comment:4 by gerard@…, 22 years ago

Priority: highlowest

comment:5 by gerard@…, 21 years ago

Priority: lowestnormal

comment:6 by gerard@…, 21 years ago

Priority: normalhigh

comment:7 by jeremy@…, 21 years ago

Resolution: fixed
Status: newclosed

Committing this change now.

comment:8 by jeremy@…, 21 years ago

Resolution: fixed
Status: closedreopened

comment:9 by gerard@…, 20 years ago

Summary: Mention which files are overwritten by a packageFix installation of the same program by more than package

Instead of just mentioning which packages overwrite, we should decide which program (if there are choices like with kill, hostname) from which package we decide is best to use and make patches to prevent installation of others like we do with hostname, libiberty and going to do with the kill programs. This will make reinstalling a random package a lot safer: it won't all of the sudden install a "wrong" version of a program.

Change the summary line to be more accurate.

comment:10 by gerard@…, 20 years ago

"kill" is a shell builtin so it doesn't matter most of the time. But some scripts will call /bin/kill so we need to have one there at least.

Three packages currently install "kill"

coreutils -> /usr/bin procps -> /bin util-linux -> /bin

I propose that we use the one from procps. The one from util-linux can be inhibited from installing by building it like so:

make HAVE_KILL=yes HAVE_SLN=yes

The one from coreutils can be removed by:

rm /usr/bin/kill

(similar to how we deal with /bin/groups from shadow).

Deal with this after 5.0 release.

comment:11 by gerard@…, 20 years ago

Cc: greg@… added

* Bug 687 has been marked as a duplicate of this bug. *

comment:12 by lizardo@…, 20 years ago

Long time ago, I reported a similar problem. See http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2003-January/031064.html (and other messages inside this thread). The information there would still be valid on LFS 5.x.

comment:13 by gerard@…, 20 years ago

Thanks Anderson, that's useful info

comment:14 by greg@…, 20 years ago

Committed some fixes to prune the number of "kill" binaries installed. This at least addresses part of the problem (Bug 687).

comment:15 by gerard@…, 20 years ago

Priority: highnormal

comment:16 by ookaze@…, 20 years ago

for the "uptime" command, I think the coreutils one is better than the procps one, as it is l10ned at least. The procps one is not l10ned, and can be omitted on install with SKIP (make SKIP='/usr/bin/uptime /usr/share/man/man1/uptime.1' install).

comment:17 by jeremy@…, 20 years ago

Owner: changed from lfs-book@… to winkie@…
Status: reopenednew

comment:18 by jeremy@…, 20 years ago

Status: newassigned

comment:19 by winkie@…, 20 years ago

Resolution: fixed
Status: assignedclosed

Fixed in 6.0

Note: See TracTickets for help on using tickets.