Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #187593 > unrolled thread

Many executables across Debian's archives share basenames

Back to article view | Back to linux.debian.user

Contents

  Many executables across Debian's archives share basenames harry666t@gmail.com (Kamil Cholewiński) - 2017-10-05 22:30 +0200
    Re: Many executables across Debian's archives share basenames Don Armstrong <don@debian.org> - 2017-10-05 22:40 +0200
      Re: Many executables across Debian's archives share basenames Zenaan Harkness <zenaan@freedbms.net> - 2017-10-06 00:20 +0200
        Re: Many executables across Debian's archives share basenames <tomas@tuxteam.de> - 2017-10-06 09:00 +0200
          Re: Many executables across Debian's archives share basenames Greg Wooledge <wooledg@eeg.ccf.org> - 2017-10-06 15:00 +0200
            Re: Many executables across Debian's archives share basenames Stefan Monnier <monnier@iro.umontreal.ca> - 2017-10-06 15:30 +0200
              Re: Many executables across Debian's archives share basenames <tomas@tuxteam.de> - 2017-10-06 15:50 +0200
                Re: Many executables across Debian's archives share basenames Jonathan Dowland <jmtd@debian.org> - 2017-10-13 14:00 +0200
                  Re: Many executables across Debian's archives share basenames <tomas@tuxteam.de> - 2017-10-13 14:40 +0200
              Re: Many executables across Debian's archives share basenames Jerome BENOIT <calculus@rezozer.net> - 2017-10-06 16:30 +0200
                Re: Many executables across Debian's archives share basenames <tomas@tuxteam.de> - 2017-10-06 16:40 +0200
            Re: Many executables across Debian's archives share basenames Zenaan Harkness <zenaan@freedbms.net> - 2017-10-06 23:20 +0200
        Re: Many executables across Debian's archives share basenames Jonathan Dowland <jmtd@debian.org> - 2017-10-13 14:00 +0200

#187593 — Many executables across Debian's archives share basenames

Hi guys,

I wrote a short script that calls "apt-file find 'bin/'", filters
results to include only stuff from /bin:/sbin:/usr/bin:/usr/sbin, and
looks for basename clashes. Turns out, in Stretch, there are 97 hits.
(If you also include /usr/games, 126.)

(Of couse, I'm counting all packages, regardless of whether they specify
"Conflicts:" or not, and regardless of whether the full name is shared,
or just the basename.)

For example, packages "389-ds-base" and "dmucs", both provie a command
called "monitor". The former's command is located in /usr/sbin, the
latter's in /usr/bin. Neither package conflicts with the other.

I think this has at least two implications:

1. Which exact executable gets called using a given command, depends
   entirely on $PATH, which, let's face it, is sometimes a mess (as
   scripts, .profile's, .bashrc's, third-party installers, automagic
   pasta, etc like to redefine and manipulate it).

Some of these commands are obviously compatible (or at least are
well-known, and have a lowest common denominator) and work fine as
drop-in replacements, like newaliases or mailq.

Some however, have different behavior (like rm from coreutils vs from
safe-rm), or are actually completely unrelated (like ztest from
zfsutils-linux and from zutils).

Scripts that rely on the existence of a command, will usually just look
for it in $PATH and assume it's the one they're expecting - I doubt many
people care to parse "foo --version" for all 17 possible implementations
of foo (including GNU Coreutils, all the BSDs, etc). I've seen this in
the wild a lot, I'm guilty of this myself, and I honestly wouldn't
expect "arcstat" to do two completely different things on a system with
ZFS, and on a system with Nordugrid (and what happens when both are
installed is entirely up to $PATH...).

2. (I know this is crazy, unsupported, violates FHS, kills kittens, and
   I'm actually Asking For Trouble by doing this, but whatever.) I can't
   safely symlink /sbin to /bin, and I can't do a /usr -> / either.

Which kinda sucks, as some Other Distros have done it and are happily
rolling with it. I know some programs will attempt weird things, or
outright freak out if this happens (I know VirtualBox used to freak out
when /usr was a symlink at all), but at least theoretically (or at least
as long as no other filename clashes happen), this should be totally
possible and kinda safe.

So, is this a bug? Is this of concern? Am I making sense?
Should I file bugs against packages that don't supply "Conflicts:"?
Should we embark on a renaming crusade? Or just leave it be?

In any case, if anyone is interested in further research, this is the
script and results for Stretch:
https://gist.github.com/rollcat/382ce16287daa03aec632aabacacd55e

Please CC me in replies, I'm not a subscriber.

Cheers!
Kamil

[toc] | [next] | [standalone]

#187594

On Thu, 05 Oct 2017, Kamil Cholewiński wrote:
> I wrote a short script that calls "apt-file find 'bin/'", filters
> results to include only stuff from /bin:/sbin:/usr/bin:/usr/sbin, and
> looks for basename clashes. Turns out, in Stretch, there are 97 hits.
> (If you also include /usr/games, 126.)

> (Of couse, I'm counting all packages, regardless of whether they specify
> "Conflicts:" or not, and regardless of whether the full name is shared,
> or just the basename.)
> 
> For example, packages "389-ds-base" and "dmucs", both provie a command
> called "monitor". The former's command is located in /usr/sbin, the
> latter's in /usr/bin. Neither package conflicts with the other.

This is sounds like a bug in both packages; monitor is way too generic
to be a name.

Everything under point 1 sounds like a bug, and probably needs a
mass-bug filing (but that should be discussed on
debian-devel@lists.debian.org, not here.)

> 2. (I know this is crazy, unsupported, violates FHS, kills kittens, and
>    I'm actually Asking For Trouble by doing this, but whatever.) I can't
>    safely symlink /sbin to /bin, and I can't do a /usr -> / either.

Part of the goal for this is being tracked in
https://wiki.debian.org/UsrMerge, and is a release goal (and the
default).

There should only be a few packages with outstanding bugs in this case:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=usrmerge;users=md@linux.it

In theory, you should be able to install usrmerge, and things should
"just work™".


-- 
Don Armstrong                      https://www.donarmstrong.com

Our days are precious, but we gladly see them going
If in their place we find a thing more precious growing
A rare, exotic plant, our gardener's heart delighting
A child whom we are teaching, a booklet we are writing
 -- Frederick Rükert _Wisdom of the Brahmans_ 
 [Hermann Hesse _Glass Bead Game_]

[toc] | [prev] | [next] | [standalone]

#187597

On Thu, Oct 05, 2017 at 01:32:47PM -0700, Don Armstrong wrote:
> On Thu, 05 Oct 2017, Kamil Cholewiński wrote:
> > I wrote a short script that calls "apt-file find 'bin/'", filters
> > results to include only stuff from /bin:/sbin:/usr/bin:/usr/sbin, and
> > looks for basename clashes. Turns out, in Stretch, there are 97 hits.
> > (If you also include /usr/games, 126.)
> 
> > (Of couse, I'm counting all packages, regardless of whether they specify
> > "Conflicts:" or not, and regardless of whether the full name is shared,
> > or just the basename.)
> > 
> > For example, packages "389-ds-base" and "dmucs", both provie a command
> > called "monitor". The former's command is located in /usr/sbin, the
> > latter's in /usr/bin. Neither package conflicts with the other.
> 
> This is sounds like a bug in both packages; monitor is way too generic
> to be a name.

Another one is "import" - should simply NEVER be a program name -
should be reserved.

man page: import - saves any visible window on an X server and
outputs it as an image file. You can capture a single window, the
entire screen, or any rectangular portion of the screen

git does it sensibly (in the last few years) with a primary basename
and sub commands.

Many of these packages (especially old X stuff) “should” migrate to
the command/subcommand way of life.

I know, I know, show me the patches...


> Everything under point 1 sounds like a bug, and probably needs a
> mass-bug filing (but that should be discussed on
> debian-devel@lists.debian.org, not here.)
> 
> > 2. (I know this is crazy, unsupported, violates FHS, kills kittens, and
> >    I'm actually Asking For Trouble by doing this, but whatever.) I can't
> >    safely symlink /sbin to /bin, and I can't do a /usr -> / either.
> 
> Part of the goal for this is being tracked in
> https://wiki.debian.org/UsrMerge, and is a release goal (and the
> default).
> 
> There should only be a few packages with outstanding bugs in this case:
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=usrmerge;users=md@linux.it
> 
> In theory, you should be able to install usrmerge, and things should
> "just work™".

New for me. Thanks.

[toc] | [prev] | [next] | [standalone]

#187609

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Oct 06, 2017 at 09:16:41AM +1100, Zenaan Harkness wrote:

[...]

> Another one is "import" - should simply NEVER be a program name -
> should be reserved.
> 
> man page: import - saves any visible window on an X server and
> outputs it as an image file. You can capture a single window, the
> entire screen, or any rectangular portion of the screen
> 
> git does it sensibly (in the last few years) with a primary basename
> and sub commands.
> 
> Many of these packages (especially old X stuff) “should” migrate to
> the command/subcommand way of life.

Funny how these young-ups tend to lump everything older than a couple
of years as "old X stuff" ;-P [1]

To be fair towards X, they were somewhat aware of this name space
problem, and most X clients (distributed by the X suite) have the
prefix "x". Might be better, but actually not bad.

Now "import" is quite another kettle of fish: it's part of the
ImageMagick suite (not much to do with X, actually), which has the
(questionable) tradition of calling its things "display", "convert",
"identify", "compare"... or even "conjure"). Now ImageMagick is so
useful that people seem to tolerate it, but a prefix (e.g. "im-")
or a super-command ("im") would be more modern, yes.

Cheers

[1] Hey, *very* tongue-in-cheek. No offense meeant. But the situation
   nearly forced me to that nonsense.

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnXKEEACgkQBcgs9XrR2kYCrQCdG8HzAxnez0uQ6ToMJEV7aasP
h8UAmwe36ipqPhS04rY/yBs5Ql2bN6jE
=ZDIj
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#187620

On Fri, Oct 06, 2017 at 08:52:49AM +0200, tomas@tuxteam.de wrote:
> Now "import" is quite another kettle of fish: it's part of the
> ImageMagick suite (not much to do with X, actually), which has the
> (questionable) tradition of calling its things "display", "convert",
> "identify", "compare"... or even "conjure"). Now ImageMagick is so
> useful that people seem to tolerate it, but a prefix (e.g. "im-")
> or a super-command ("im") would be more modern, yes.

ImageMagick only gets away with it because of its age and ubiquity.
It's grandfathered in.

[toc] | [prev] | [next] | [standalone]

#187626

>> Now "import" is quite another kettle of fish: it's part of the
>> ImageMagick suite (not much to do with X, actually), which has the
>> (questionable) tradition of calling its things "display", "convert",
>> "identify", "compare"... or even "conjure"). Now ImageMagick is so
>> useful that people seem to tolerate it, but a prefix (e.g. "im-")
>> or a super-command ("im") would be more modern, yes.
> ImageMagick only gets away with it because of its age and ubiquity.
> It's grandfathered in.

How 'bout installing imagemagick executables into
a /usr/bin/im/ subdirectory?
This way, you can refer to it via `im/convert` but if you prefer to 
use the "grandfather" name, you can just add /usr/bin/im/ to your PATH.


        Stefan

[toc] | [prev] | [next] | [standalone]

#187629

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Oct 06, 2017 at 09:24:11AM -0400, Stefan Monnier wrote:
> >> Now "import" is quite another kettle of fish: it's part of the
> >> ImageMagick suite (not much to do with X, actually), which has the
> >> (questionable) tradition of calling its things "display", "convert",
> >> "identify", "compare"... or even "conjure"). Now ImageMagick is so
> >> useful that people seem to tolerate it, but a prefix (e.g. "im-")
> >> or a super-command ("im") would be more modern, yes.
> > ImageMagick only gets away with it because of its age and ubiquity.
> > It's grandfathered in.
> 
> How 'bout installing imagemagick executables into
> a /usr/bin/im/ subdirectory?
> This way, you can refer to it via `im/convert` but if you prefer to 
> use the "grandfather" name, you can just add /usr/bin/im/ to your PATH.

The problem with grandparents is that everyone has to agree. Just imagine
a distro doing that. Torches and pitchforks! ;-)

(And while we're painting the shed, I'd go for a /usr/bin/im.d, with a
dispatcher script in /usr/bin/im or something...)

Of course, a sysadmin could do that on her box...

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnXiHgACgkQBcgs9XrR2kYXAwCePGDD2ipc1tmUl6OknUMuHZaq
AucAni1teAqtW9AWqWgMmm+d95afyjkm
=96E1
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#187854

On Fri, Oct 06, 2017 at 03:43:20PM +0200, tomas@tuxteam.de wrote:
>(And while we're painting the shed, I'd go for a /usr/bin/im.d, with a
>dispatcher script in /usr/bin/im or something...)

Software Collections https://www.softwarecollections.org have a pretty
robust way of managing this sort of thing.


-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]

#187855

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Oct 13, 2017 at 12:56:36PM +0100, Jonathan Dowland wrote:
> On Fri, Oct 06, 2017 at 03:43:20PM +0200, tomas@tuxteam.de wrote:
> >(And while we're painting the shed, I'd go for a /usr/bin/im.d, with a
> >dispatcher script in /usr/bin/im or something...)
> 
> Software Collections https://www.softwarecollections.org have a pretty
> robust way of managing this sort of thing.

Well, yes. But that would be painting the shed with an aircraft carrier ;-)

FWIW, if going that far, I'd rather prefer Gnu Guix [1] which also
manages the repeatable build of specific software versions.

But back on topic, I think in the current case (old, well established
binaries from X or ImageMagick) it just makes sense to live with
the inconsistencies (and keep the lessons for when we go for a
new system). Many younger generation (collections of) binaries
(ip, openssl, git) tend to do the right thing anyway.

Cheers

[1] https://savannah.gnu.org/projects/guix/
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlngsdoACgkQBcgs9XrR2kafcgCeLKEq+75ai9WLSzQx7FFW0VbU
njEAn1atZdXY7fjex8Z3vWmoswTJVVQ3
=Gi5S
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#187631

[Multipart message — attachments visible in raw view] — view raw

Hello,

On 06/10/17 17:24, Stefan Monnier wrote:
>>> Now "import" is quite another kettle of fish: it's part of the
>>> ImageMagick suite (not much to do with X, actually), which has the
>>> (questionable) tradition of calling its things "display", "convert",
>>> "identify", "compare"... or even "conjure"). Now ImageMagick is so
>>> useful that people seem to tolerate it, but a prefix (e.g. "im-")
>>> or a super-command ("im") would be more modern, yes.
>> ImageMagick only gets away with it because of its age and ubiquity.
>> It's grandfathered in.
> 
> How 'bout installing imagemagick executables into
> a /usr/bin/im/ subdirectory?
> This way, you can refer to it via `im/convert` but if you prefer to 
> use the "grandfather" name, you can just add /usr/bin/im/ to your PATH.
> 

We can also add the prefix im- to each executable.
For instance, the tools coming with the nauty package are prefixed with nauty-
to avoid name collision.

Jerome



> 
>         Stefan
> 

-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calculus@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B

[toc] | [prev] | [next] | [standalone]

#187632

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Oct 06, 2017 at 06:06:33PM +0400, Jerome BENOIT wrote:
> Hello,
> 
> On 06/10/17 17:24, Stefan Monnier wrote:

[...]

> We can also add the prefix im- to each executable.
> For instance, the tools coming with the nauty package are prefixed with nauty-
> to avoid name collision.

Yes, but all this schemes would kill existing scripts (that's why I mentioned
pitchforks ;-)

Stefan's approach would have at least the advantage that one could skirt the
problem by augmenting $PATH (unless the scripts call the ImageMagick binaries
with full path).

I don't think a distro would want to do that. I'd think these horses left
the barn long time ago.

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEUEARECAAYFAlnXk3sACgkQBcgs9XrR2kaPMwCY7ugYWXwvCAtr/VHrV/S00Fbt
iwCffambMFiEZu4XLoPYJ0M7KRsr3mU=
=+azB
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#187653

On Fri, Oct 06, 2017 at 08:56:08AM -0400, Greg Wooledge wrote:
> On Fri, Oct 06, 2017 at 08:52:49AM +0200, tomas@tuxteam.de wrote:
> > Now "import" is quite another kettle of fish: it's part of the
> > ImageMagick suite (not much to do with X, actually), which has the
> > (questionable) tradition of calling its things "display", "convert",
> > "identify", "compare"... or even "conjure"). Now ImageMagick is so
> > useful that people seem to tolerate it, but a prefix (e.g. "im-")
> > or a super-command ("im") would be more modern, yes.
> 
> ImageMagick only gets away with it because of its age and ubiquity.
> It's grandfathered in.

Ah yes, I mixed that up - it's ImageMagick, not X.

ImageMagick needs a patch to fix this!  There is a new, not
particularly shiny but rather effective hierarchical naming Buddha
path which must be followed for our collective command namespace
sanity.

Could even be done by wrapper script of course... hmmm


On Fri, Oct 06, 2017 at 04:30:19PM +0200, tomas@tuxteam.de wrote:
> On Fri, Oct 06, 2017 at 06:06:33PM +0400, Jerome BENOIT wrote:
> > Hello,
> >⋅
> > On 06/10/17 17:24, Stefan Monnier wrote:
>⋅
> [...]
>⋅
> > We can also add the prefix im- to each executable.
> > For instance, the tools coming with the nauty package are
> > prefixed with nauty-
> > to avoid name collision.
>
> Yes, but all this schemes would kill existing scripts (that's why I
> mentioned pitchforks ;-)
>
> Stefan's approach would have at least the advantage that one could
> skirt the problem by augmenting $PATH (unless the scripts call the
> ImageMagick binaries with full path).
>
> I don't think a distro would want to do that. I'd think these
> horses left the barn long time ago.

Bah ... just have a package install option "namespace" and those who
don't want it don't choose it.

There comes a time in every distro's life when it must grab itself by
its bootlaces, lift itself into the sky of namespace serenity and
float off into nirvana with just a little monkey magic.

A patch a day keeps the pitchforks at bay :)


At least now that I know it's im, and not x, I can give it my royal
boot yo!

 <‼‼MWWAAAHAHAHHAHAHAHAHAAAAAAAAAAAA‼‼>

[toc] | [prev] | [next] | [standalone]

#187853

On Fri, Oct 06, 2017 at 09:16:41AM +1100, Zenaan Harkness wrote:
>Many of these packages (especially old X stuff) “should” migrate to
>the command/subcommand way of life.

That might be too much work and result in compatibility problems, but
maybe instead we could move all the X stuff to another path, I dunno,
like /usr/share/X11R7/bin?

(/s)

-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web