3 ms·

(Referring to https://www.gnu.org/software/stow/manual/stow.html#Other-FSF-Software https://www.gnu.org/software/stow/manual/stow.html#Other-FSF...) They serve

(Referring to https://www.gnu.org/software/stow/manual/stow.html#Other-FSF-Software https://www.gnu.org/software/stow/manual/stow.html#Other-FSF...) They serve two different purposes. DESTDIR places files in a staging directory, e.g. to be packaged into a tarball. In your example, you will end up with the program at /usr/local/stow/whatever/usr/local/bin, which I'm guessing Stow is trying to avoid, because it's ugly and the extra directories are unnecessary. Not wrong, though. With their approach, it ends up at /usr/local/stow/whatever/bin.

deleted 3y ago
[deleted]
kazinator 3y ago
Right. So if the package supports install time prefix with no hassle, it could be done with make DESTDIR=/usr/local/stow/whatever prefix=/ to get rid of the usr/local components. If the prefix override causes a problem, then just live with the extra components. I'm guessing that in that case you tell stow that your package root is at /usr/local/stow/whatever/usr/local. Stow doesn't care about the extra components; your package can be anywhere you like, right?
- grumbel 3y ago
  That's not right either. The --prefix needs to be /usr/local or /usr/local/stow/package-1.0, otherwise many packages won't find their own files. The prefix path will get compiled into the binary or configuration for a lot of packages, it's not just an install time thing. Using --prefix=/usr/local/stow/package-1.0 is problematic whenever you have a package with plugins, themes or other stuff, as those go to /usr/local/share/package/... while the app is looking in /usr/local/stow/package-1.0/share/package/ Using DESTDIR and manually removing the usr/local from the directory tree is what I would consider the correct way, even if a bit annoying. Either way, these days I would just recommend to use Nix instead, which is a much more complete solution for what stow tries to do.
  - kazinator 3y ago
    I understand the compile-time prefix. But in some projects, you can override the configured prefix variable during "make install" without changing anything in the package; the install steps will just accept those paths, as a hack for shortening the paths, in packages where that works. The Stow documentation mentions this also.

deleted 3y ago

[deleted]

kazinator 3y ago

Right. So if the package supports install time prefix with no hassle, it could be done with make DESTDIR=/usr/local/stow/whatever prefix=/ to get rid of the usr/local components. If the prefix override causes a problem, then just live with the extra components. I'm guessing that in that case you tell stow that your package root is at /usr/local/stow/whatever/usr/local. Stow doesn't care about the extra components; your package can be anywhere you like, right?

grumbel 3y ago
That's not right either. The --prefix needs to be /usr/local or /usr/local/stow/package-1.0, otherwise many packages won't find their own files. The prefix path will get compiled into the binary or configuration for a lot of packages, it's not just an install time thing. Using --prefix=/usr/local/stow/package-1.0 is problematic whenever you have a package with plugins, themes or other stuff, as those go to /usr/local/share/package/... while the app is looking in /usr/local/stow/package-1.0/share/package/ Using DESTDIR and manually removing the usr/local from the directory tree is what I would consider the correct way, even if a bit annoying. Either way, these days I would just recommend to use Nix instead, which is a much more complete solution for what stow tries to do.
- kazinator 3y ago
  I understand the compile-time prefix. But in some projects, you can override the configured prefix variable during "make install" without changing anything in the package; the install steps will just accept those paths, as a hack for shortening the paths, in packages where that works. The Stow documentation mentions this also.