[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: column - how to get it updated?



On Thu, 25 Jul 2019, David Wright wrote:

On Fri 26 Jul 2019 at 02:57:40 (+0000), davidson wrote:
On Thu, 25 Jul 2019, Richard Hector wrote:

On 25/07/19 3:26 PM, Andrew Punnett wrote:
Hi,

Debian currently uses the `column` command from FreeBSD. However,
the `column` command included in the util-linux package from the
Linux Kernel Organisation is much more useful.

There is a bug report about this at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908975, which
ends with the Debian util-linux package maintainer stating:

[SNIPPED, in order to insert immediately-prior context from bugreport]

"If you want the bsdutils to provide (util-linux version of) the tools
you need to convince the bsdmainutils maintainers that they should
stop shipping theirs, since we can't have file collisions between
different packages (ie. debian policy forbids two different packages
to provide the same file)."

"Until you've convinced the bsdmainutils maintainers we should
change to the util-linux versions, there's nothing that can be done
on the util-linux/bsdutils side - thus the wontfix tag."

How can we persuade the Debian bsdmainutils package maintainers to
allow the Linux version of column to be shipped?

Can't they all get along by using /etc/alternatives?

I don't think file collisions are the kind of thing the debian
alternatives system is meant to solve.

That's news to me. I was under the impression that /etc/alternatives
is the mechanism by which "rename" can be used for two different
commands, prename and file-rename, which would otherwise collide
with the name /usr/bin/rename.

TL;DNR: You might be able to call any cat in the neigborhood with
"Here, kitty kitty." That doesn't make "Kitty" its name.

I'll try to elaborate as briefly as I can (though I lack the Curt's
flair for brevity).

I think of the debian alternatives system like a sort of Yellow Pages,
where the local administrator gets to determine the relative
prominence of entries under each generic service/accomodation.

So if my needs are merely generic, I can order {a pizza, a cab,...}
anywhere, even in an unfamiliar town. The debian alternatives system
curates a collection of "generic names"* (like /usr/bin/Pizzeria in my
vivid imagination, or /usr/bin/rename in your chosen example) to
support this, to represent *sorts* of services/accomodations
generically desired, and provides conventions so that merely knowing
the type of thing you want is sufficient to obtain some instance of it
(as long as some instance is installed).

It doesn't mean all the pizza vendors can finally all name their
respective pizzerias "Pizzeria," free of confusion. ("Hooray, someone
invented Yellow Pages! Let's name all the things 'Hodor!'") Likewise,
is it not fortunate that the two different commands in your
illustration, named "prename" and "file-rename", do have *different*
names?

That is all.

[*] In the parlance of update-alternatives(1).


(I realise that, as of stretch, one of these versions of rename becomes
deprecated and will be withdrawn in future, but it's the example that
comes immediately to mind because they've been around for many years.)

$ rename
Usage:
   rename [ -h|-m|-V ] [ -v ] [ -n ] [ -f ] [ -e|-E perlexpr]*|perlexpr
   [ files ]

$ rename # having just removed package rename
Deprecated program in use: rename as shipped with the Debian perl
package will be removed after the release of stretch. Please install
the separate 'rename' package which will provide the same command.

Usage: rename [-v] [-n] [-f] perlexpr [filenames]
$

Cheers,
David.


--
 The day will come              |  Last words, August Spies (1855--1887).
 When our silence will be       |  Hanged, by the U.S. state of Illinois,
 More powerful than             |  alongside fellow journalists
 The voices you strangle today  |  Adolf Fischer and Albert Parsons.


Reply to: