[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.61.0612212106560.10411@yvahk01.tjqt.qr>
Date: Thu, 21 Dec 2006 21:09:47 +0100 (MET)
From: Jan Engelhardt <jengelh@...ux01.gwdg.de>
To: Albert Cahalan <acahalan@...il.com>
cc: kzak@...hat.com, hvogel@...e.de, olh@...e.de, hpa@...or.com,
linux-kernel@...r.kernel.org, arekm@...en.pl,
util-linux-ng@...r.kernel.org
Subject: Re: util-linux: orphan
>> What about merging util-linux and procps?
>
> How? Which way?
In that all the following tools (and possibly files) which are
returned by `rpm ql procps` replace the util-linux counterparts, if
any. Note that rpm -ql might return less programs than actually
present in procps, since distributors need to choose which program to
pick from what {util-linux or procps}.
21:07 ichi:~ > rpm -ql procps
/bin/ps
/etc/init.d/boot.sysctl
/etc/sysctl.conf
/etc/xinetd.d/systat
/sbin/sysctl
/usr/bin/free
/usr/bin/pgrep
/usr/bin/pkill
/usr/bin/pmap
/usr/bin/pwdx
/usr/bin/skill
/usr/bin/slabtop
/usr/bin/snice
/usr/bin/tload
/usr/bin/top
/usr/bin/vmstat
/usr/bin/w
/usr/bin/watch
+ the stuff in /usr/share/doc and /usr/share/man
with the idea that you retain maintership over these. So my proposal/idea was
just one of how to package it.
> being bogged down in problems. One by one, the various
> Linux distributions switched over to my version of the code.
>
> So as you may imagine, I'd be rather nervous about letting
> procps get into that situation again. Bugs are yucky. Having
> multiple committers and no testing is a sure path to ruin.
-`J'
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists