Do no conflict with uutils project

[oech3]

Describe the feature/solution

Provide an easy method to split files for coreutils.

Default make options provides /usr/share/bash-completion/completions/chmod which conflicts with compat package.

(Ofcause best solution may moving them to GNU coreutils project...)

Maintenance (please complete the following information)

• This is a request about packaging layout

[scop]

So the mechanism we have available for this is prefixing the files we ship with an underscore, search around the source tree for "fallback" if interested about the details. TL;DR if we do that, it'll fix the file level conflicts, and if there is an underscoreless filename present, it'll take precedence over the underscored one.

As it stands, AFAIU what's possibly conflicting from uutils is

• https://github.com/uutils/coreutils/blob/4bd3b70774e250f7172c5babcd9b7cfc387bf8e2/GNUmakefile#L381
• https://github.com/uutils/coreutils/blob/4bd3b70774e250f7172c5babcd9b7cfc387bf8e2/GNUmakefile#L282-L285
• https://github.com/uutils/coreutils/blob/4bd3b70774e250f7172c5babcd9b7cfc387bf8e2/GNUmakefile#L75-L185

So we could rename all our possibly conflicting files this way, but I started to wonder if we should just go ahead and rename everything this way already to prevent these particular conflicts and future ones like it, #1386

[oech3]

if we should just go ahead and rename everything this way already to prevent these particular conflicts and future ones

It looks cleanest approarch for every alternatives in the feature.

[oech3]

Is sending a PR to rename files fine for coreutils, stty, runcon, chcon and

Currently defined functions:

    [, arch, b2sum, b3sum, base32, base64, basename, basenc, cat, chgrp, chmod,
    chown, chroot, cksum, comm, cp, csplit, cut, date, dd, df, dir, dircolors,
    dirname, du, echo, env, expand, expr, factor, false, fmt, fold, groups,
    hashsum, head, hostid, hostname, id, install, join, kill, link, ln, logname,
    ls, md5sum, mkdir, mkfifo, mknod, mktemp, more, mv, nice, nl, nohup, nproc,
    numfmt, od, paste, pathchk, pinky, pr, printenv, printf, ptx, pwd, readlink,
    realpath, rm, rmdir, seq, sha1sum, sha224sum, sha256sum, sha3-224sum, sha3-
    256sum, sha3-384sum, sha3-512sum, sha384sum, sha3sum, sha512sum, shake128sum,
    shake256sum, shred, shuf, sleep, sort, split, stat, stdbuf, sum, sync, tac,
    tail, tee, test, timeout, touch, tr, true, truncate, tsort, tty, uname,
    unexpand, uniq, unlink, uptime, users, vdir, wc, who, whoami, yes

at a monent?

[oech3]

@akinomyoga At least, I can ask project to install files at *.bash now. OK? Not sure about priority for loading.

[akinomyoga]

That could be a clever idea.

In the current implementation, the completion setting without .bash is preferred to the one with .bash:

bash-completion/bash_completion

Line 3390 in 360b87d

for compfile in "$prefix$cmdname" "$prefix$cmdname.bash"; do

So the completion file wouldn't be enabled until bash-completion 2.18 is packaged in the distribution. Nevertheless, the conflict is avoided with all versions of bash-completion, including the older ones.

[oech3]

Thankyou.