3 ms·

This disregards a common use of the Makefile: compiling software from source, bypassing the use of a package manager in the first place. Yes, software devs shou

This disregards a common use of the Makefile: compiling software from source, bypassing the use of a package manager in the first place. Yes, software devs should be providing a Makefile that is friendly for package managers to wrap. But the best software provides a Makefile usable on all platforms it supports, without the expectation that a package manager will be involved. Sure, you can install each compiled package to its own subdirectory under /usr/local/, but then their binaries are not located in a default PATH. Whether performed accidentally or intentionally, installing to /usr/local/ prefix (/usr/local/bin/, etc.), should not result in having no way of automating an uninstall of those files.

dozzie 10y ago
> This disregards a common use of the Makefile: compiling software from source, bypassing the use of a package manager in the first place. Most of the executions (those actually used in the wild) of this strategy are quite stupid. Add to that the fact that building packages with distribution's tools is quite easy, and now on top of that add fpm, which produces terrible packages and should be banned for upstream maintainers, but for a desktop installation they're perfectly usable, and checkinstall, which is more than fifteen years old. > Yes, software devs should be providing a Makefile that is friendly for package managers to wrap. After what I said to steveklabnik (https://news.ycombinator.com/item?id=12014815 https://news.ycombinator.com/item?id=12014815): build script (whatever it is, it doesn't need to be makefile) should never touch network when building the project and should not expect libraries in any particular place (especially not the directory with the sources nor $HOME/.whatever). This is enough for build script to be friendly towards package managers and none of the package managers expect anything more from the source tarball. > But the best software provides a Makefile usable on all platforms it supports, without the expectation that a package manager will be involved. Yes, of course. But package managers really don't expect anything more than a good build script should provide: no network, no hardcoded library paths, only building the artifacts from the locally accessible sources. And maybe a target that puts the artifacts in appropriate places under $DESTDIR, but this is often optional. There's nothing more than one could do by hand, installing stuff into /opt/$someproject directory, so it can be safely removed altogether, and add symlinks to /usr/local/bin, so they're in typical $PATH. Package managers actually springed from automating what people did manually just before. > Whether performed accidentally or intentionally, installing to /usr/local/ prefix (/usr/local/bin/, etc.), should not result in having no way of automating an uninstall of those files. Let's not make the users mentally disabled people. Do we really need to protect them from all their mistakes? What would be next, adding a recycle bin for files removed with `rm'? OK, I'm somewhat exaggregating here. But where's the line of that protection?
- hnbroseph 10y ago
  > exaggregating this could make for a cool portmanteau.
  - dozzie 10y ago
    Oh, my. My spelling still leaves room for improvement. Sorry, I thought I know how to write this word (now I know I don't know).

dozzie 10y ago

> This disregards a common use of the Makefile: compiling software from source, bypassing the use of a package manager in the first place. Most of the executions (those actually used in the wild) of this strategy are quite stupid. Add to that the fact that building packages with distribution's tools is quite easy, and now on top of that add fpm, which produces terrible packages and should be banned for upstream maintainers, but for a desktop installation they're perfectly usable, and checkinstall, which is more than fifteen years old. > Yes, software devs should be providing a Makefile that is friendly for package managers to wrap. After what I said to steveklabnik (https://news.ycombinator.com/item?id=12014815 https://news.ycombinator.com/item?id=12014815): build script (whatever it is, it doesn't need to be makefile) should never touch network when building the project and should not expect libraries in any particular place (especially not the directory with the sources nor $HOME/.whatever). This is enough for build script to be friendly towards package managers and none of the package managers expect anything more from the source tarball. > But the best software provides a Makefile usable on all platforms it supports, without the expectation that a package manager will be involved. Yes, of course. But package managers really don't expect anything more than a good build script should provide: no network, no hardcoded library paths, only building the artifacts from the locally accessible sources. And maybe a target that puts the artifacts in appropriate places under $DESTDIR, but this is often optional. There's nothing more than one could do by hand, installing stuff into /opt/$someproject directory, so it can be safely removed altogether, and add symlinks to /usr/local/bin, so they're in typical $PATH. Package managers actually springed from automating what people did manually just before. > Whether performed accidentally or intentionally, installing to /usr/local/ prefix (/usr/local/bin/, etc.), should not result in having no way of automating an uninstall of those files. Let's not make the users mentally disabled people. Do we really need to protect them from all their mistakes? What would be next, adding a recycle bin for files removed with `rm'? OK, I'm somewhat exaggregating here. But where's the line of that protection?

hnbroseph 10y ago
> exaggregating this could make for a cool portmanteau.
- dozzie 10y ago
  Oh, my. My spelling still leaves room for improvement. Sorry, I thought I know how to write this word (now I know I don't know).