3 ms·

> Unless the user has existing files with the same names there. Or they edit a config file you placed in /etc/ and then they run the installer for a new version

> Unless the user has existing files with the same names there. Or they edit a config file you placed in /etc/ and then they run the installer for a new version. Oh so now your "simple" installer has to handle version upgrades, and file conflicts? And these scenarios would make deb's and rpm's bail out as well. > No? I have a makefile which can do the actual building and installing. dh_make will generate a debian directory, and debuild will call this makefile. An RPM specfile also will have calls to make build, make install, etc. A makefile is a script. An RPM specfile is also a script. > If I haven't covered some Distro, it's hardly difficult to give them a .tar.gz containing the tree created by the aforementioned `make install`. This is still less work than your special installer script. People will also be much less likely to actually install your software this way.

stephenr 11y ago
> And these scenarios would make deb's and rpm's bail out as well. Conflicting config files can be handled intelligently by deb and rpm based package managers. Does your install script identify whether or not the user made any changes to the config file your previous installer script placed in /etc 9 months ago, and give them options (including viewing a diff and an interactive shell while installation is paused) about how to handle it if they did make changes, and use the new one if they just used the default? I doubt it somehow. > A makefile is a script How do you build the binaries that your special install script installs then? My point is that package building tools generally leverage an existing makefile that you would already have. > People will also be much less likely to actually install your software this way. Given that my software targets Linux servers, I actually imagine they're more likely to install from my packages (or an archive on a weird unsupported distro) than from your home-grown install script.
- tokenizerrr 11y ago
  > Does your install script identify whether or not the user made any changes to the config file your previous installer script placed in /etc 9 months ago, and give them options (including viewing a diff and an interactive shell while installation is paused) about how to handle it if they did make changes, and use the new one if they just used the default? I doubt it somehow. It doesn't overwrite anything because the file is intended to be modified. Problem solved. > How do you build the binaries that your special install script installs then? My point is that package building tools generally leverage an existing makefile that you would already have. I don't write C, I usually write python (interpreter already installed), Go (static binary) or sh (interpreter already installed). These never use makefiles, so I'd have to script a new one for this. And then there's dealing with all the different tools to generate the different kind of packages. > Given that my software targets Linux servers, I actually imagine they're more likely to install from my packages (or an archive on a weird unsupported distro) than from your home-grown install script. I was comparing the install script with providing a .tar.gz file with some files in it. Obviously people would prefer for packages for their obscure system, but alas, they don't exist.

stephenr 11y ago

> And these scenarios would make deb's and rpm's bail out as well. Conflicting config files can be handled intelligently by deb and rpm based package managers. Does your install script identify whether or not the user made any changes to the config file your previous installer script placed in /etc 9 months ago, and give them options (including viewing a diff and an interactive shell while installation is paused) about how to handle it if they did make changes, and use the new one if they just used the default? I doubt it somehow. > A makefile is a script How do you build the binaries that your special install script installs then? My point is that package building tools generally leverage an existing makefile that you would already have. > People will also be much less likely to actually install your software this way. Given that my software targets Linux servers, I actually imagine they're more likely to install from my packages (or an archive on a weird unsupported distro) than from your home-grown install script.

tokenizerrr 11y ago
> Does your install script identify whether or not the user made any changes to the config file your previous installer script placed in /etc 9 months ago, and give them options (including viewing a diff and an interactive shell while installation is paused) about how to handle it if they did make changes, and use the new one if they just used the default? I doubt it somehow. It doesn't overwrite anything because the file is intended to be modified. Problem solved. > How do you build the binaries that your special install script installs then? My point is that package building tools generally leverage an existing makefile that you would already have. I don't write C, I usually write python (interpreter already installed), Go (static binary) or sh (interpreter already installed). These never use makefiles, so I'd have to script a new one for this. And then there's dealing with all the different tools to generate the different kind of packages. > Given that my software targets Linux servers, I actually imagine they're more likely to install from my packages (or an archive on a weird unsupported distro) than from your home-grown install script. I was comparing the install script with providing a .tar.gz file with some files in it. Obviously people would prefer for packages for their obscure system, but alas, they don't exist.