>> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
