7 ms·
> Yet it forgets the MOST important thing: make uninstall. Why it forgets that? It's not the job of a library build system to install or uninstall things in yo
by dozzie 10y ago
> Yet it forgets the MOST important thing: make uninstall.
Why it forgets that? It's not the job of a library build system to install
or uninstall things in your system. It's a job for your system's package
manager.
Makefile that has a target (historically called "install") that puts things in
appropriate places in a chroot-like manner is just good enough.
- vog 10y agoI fully agree! Moreover, I tend to see "make install" not as actual installation command (that's indeed the task of a package manager), but more of an "extract the relevant build results". With that in mind, I prefer packages that have a clear "build destination" folder which is filled (and updated) by a plain "make", so that "make install" isn't even needed anymore, because installation then boils down to a trivial "cp -R" command. This, of course, requires a disciplined separation of intermediate build results from the final build results. But that shouldn't be too hard. In fact, this may be simpler than writing down a good "make install" in the first place.
- developer2 10y agoThis 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?