Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



Stick the binary wherever your textile is, copy it to path on setup.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: