4 ms·

you raise a great point. why not install the package, then delete the /usr/bin files you don't need? would it solve the problem if the author namespaced the co

you raise a great point. why not install the package, then delete the /usr/bin files you don't need? would it solve the problem if the author namespaced the commands with a hyphenated prefix? curious about these considerations, which it seems like you've spent time thinking about. what do you see as the "best practices" regarding a set of utilities that are maintained and published together?

krick 6y ago
In a most general sense, this is not really a problem of moreutils, but of how tools are installed/distributed in Linux distributions. But since we have to be realistic, yes, package authors should take such problems into consideration. I think if tools are absolutely unrelated, they just should be distributed as a separate packages. GNU coreutils is tolerated mostly because it's so ubiquitous (so much, that it causes Stallman to grumble about "you mean GNU/Linux, not Linux"). moreutils is late to the party, it isn't ubiquitous, and the usefulness of any tool in the package is questionable, so the author really shouldn't be so brave to assume that if he thought he needed all of them, everyone will. If there is a reason enough to distribute a package with several separate callable binaries (as with ImageMagick), I think git or GraphicsMagick are perfect examples of how it should be done. Hypenated prefix is also ok. Even if your tool is supposed to be used by somebody 50 times a day, too long of a name isn't really a problem, since user can always just make an alias (as I do with most of the tools I use frequently). Sure you can always combine binaries from 2 packages manually, but as I said, it just requires some tinkering, so I cannot simply have in some textfile a list of utils to install on a new PC in a matter of minutes.
- boomboomsubban 6y ago
  Stick the binary wherever your textile is, copy it to path on setup.
SQueeeeeL 6y ago
Excepting the user to have to clean cruft to install the software they want is a terrible philosophy and not in line with Unix at all, now you've created a situation where to install "sponge" you need to place 10 other random binaries onto your machine and know enough about the process to know to delete them...
chalst 6y ago
Or use Nix to install these kinds of package and only create the symlinks you care about.
tingletech 6y ago
I remember building the gnu core tools on sun os and solaris boxes. I had a license to the compiler from sun, then I would get GNU compiler going, then I'd get the whole GNUniverse going. The GNU build/install process let you set a prefix, so it was customary to specify `g` get prefixed, so `gmore` and `gcd` etc. if you were afraid of breaking old user scripts that used the sun versions. The build for this looks pretty simple. I cloned the source, ran "make". I got some XML errors about docbook, but it did create a `sponge` otool -L sponge sponge: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) looks like one could copy it to `~/bin/`
vimax 6y ago
Your package manager will still see that the two packages want to own the same file and give you a conflict error unless you force install which it's very messy. Namespacing the commands would solve this. But in general it is bad practice to package a bunch of unrelated tools together. You should be able to install them separately to only have what you need. Youd want different packages for each command or sets of related commands with common dependencies. And then have a meta package that includes all of your packages for people who want to install it all in one go.
zzo38computer 6y ago
Another alternative might be, if the programs are single source code files and can mostly work by itself, you can just compile the ones you need and put the binaries where you need them, rather than installing a package.

krick 6y ago

In a most general sense, this is not really a problem of moreutils, but of how tools are installed/distributed in Linux distributions. But since we have to be realistic, yes, package authors should take such problems into consideration. I think if tools are absolutely unrelated, they just should be distributed as a separate packages. GNU coreutils is tolerated mostly because it's so ubiquitous (so much, that it causes Stallman to grumble about "you mean GNU/Linux, not Linux"). moreutils is late to the party, it isn't ubiquitous, and the usefulness of any tool in the package is questionable, so the author really shouldn't be so brave to assume that if he thought he needed all of them, everyone will. If there is a reason enough to distribute a package with several separate callable binaries (as with ImageMagick), I think git or GraphicsMagick are perfect examples of how it should be done. Hypenated prefix is also ok. Even if your tool is supposed to be used by somebody 50 times a day, too long of a name isn't really a problem, since user can always just make an alias (as I do with most of the tools I use frequently). Sure you can always combine binaries from 2 packages manually, but as I said, it just requires some tinkering, so I cannot simply have in some textfile a list of utils to install on a new PC in a matter of minutes.

boomboomsubban 6y ago
Stick the binary wherever your textile is, copy it to path on setup.

SQueeeeeL 6y ago

Excepting the user to have to clean cruft to install the software they want is a terrible philosophy and not in line with Unix at all, now you've created a situation where to install "sponge" you need to place 10 other random binaries onto your machine and know enough about the process to know to delete them...

chalst 6y ago

Or use Nix to install these kinds of package and only create the symlinks you care about.

tingletech 6y ago

I remember building the gnu core tools on sun os and solaris boxes. I had a license to the compiler from sun, then I would get GNU compiler going, then I'd get the whole GNUniverse going. The GNU build/install process let you set a prefix, so it was customary to specify `g` get prefixed, so `gmore` and `gcd` etc. if you were afraid of breaking old user scripts that used the sun versions. The build for this looks pretty simple. I cloned the source, ran "make". I got some XML errors about docbook, but it did create a `sponge` otool -L sponge sponge: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) looks like one could copy it to `~/bin/`

vimax 6y ago

Your package manager will still see that the two packages want to own the same file and give you a conflict error unless you force install which it's very messy. Namespacing the commands would solve this. But in general it is bad practice to package a bunch of unrelated tools together. You should be able to install them separately to only have what you need. Youd want different packages for each command or sets of related commands with common dependencies. And then have a meta package that includes all of your packages for people who want to install it all in one go.

zzo38computer 6y ago

Another alternative might be, if the programs are single source code files and can mostly work by itself, you can just compile the ones you need and put the binaries where you need them, rather than installing a package.