[arch-dev-public] [RFC] util-linux-2.22 new binaries - conflicts

[Dave Reisner]

On Mon, Jul 30, 2012 at 02:48:41AM +0200, Tom Gundersen wrote:
> Hi guys,
> 
> util-linux-2.22-rc1 is available, and I'm preparing for the final release.
>
> A few binaries have been merged from other packages, so we need to
> decide where we want to let them live
> 
>  * /bin/kill has been merged from the procps-ng project. Opinions?

util-linux has always had its own kill implementation. It does have some
nice improvements over the procps code, including the ability to kill
processes by name. It also understands the RT signals by name and has
some advanced (optional) behavior with using sigqueue(2) instead of
kill(2). I'm in favor of using this, but I'm also fairly sure procps's
implementation isn't going anywhere. I recall there was some talk about
this in #util-linux, but I don't remember any specifics.

Fun fact: your shell provides a kill builtin so that it's able to
interact with controlled jobs. I suspect this is the kill "binary" that
gets used most often.

>  * /usr/bin/eject has been merged from the long-dead eject project. I
> intend to drop the "eject" package and let util-linux provide this.

Yup, this is a no brainer.

>  * /bin/su has been merged from coreutils. This is going to get
> dropped from there so we want this, unless I'm mistaken?

Yup, util-linux needs to provide this.

>  * /sbin/sulogin, /usr/bin/last and /usr/bin/utmpdump have been merged
> from sysvinit. This makes sense as we want those even when sysvinit is
> not installed. Objections?

Nope, last was not merged. I'm in favor of using the other two so that
we're not init-dependent.

I propose we split sysvinit into the "init" pieces and the "tools" pieces,
similar to systemd{,-tools}. There's other binaries that have yet to be
merged, and I've heard requests for them recently. I don't know of any
timeline for merging these things, but I assume that we'll see some of
the more prominent sysvinit tools merged for 2.23.

>  * /bin/wdctl and /usr/bin/lslocks appear to be new.

lslocks is a reimplementation of lslk, an ancient and deficient tool
which was given up on over a decade ago. It's fairly nifty.

> I threw up some packages, if people want to take them for a spin (note
> that there will be file conflicts):
> <https://dev.archlinux.org/~tomegun/util-linux-2.22-0.1-i686.pkg.tar.xz>
> <https://dev.archlinux.org/~tomegun/util-linux-2.22-0.1-x86_64.pkg.tar.xz>
> 
> Cheers,
> 
> Tom