4 ms·

Could you point me to the better way of installing software that will work on all Linux distros?

by tokenizerrr 11y ago

stephenr 11y ago
District-appropriate packages. Use the right fucking tool for the job.
- tokenizerrr 11y ago
  That will not work on all Linux distros. That is writing a specific installer for each distro, which does not satisfy my requirements and as such is not the right tool for the job.
  - stephenr 11y ago
    > That will not work on all Linux distros The result of the work to create packages using the major packaging formats will produce a series of packages that combined, will arguably work better, on more distros than your home-grown installer. > That is writing a specific installer What makes you think creating e.g. a debian package equates to "writing a specific installer". The whole point of packages is that you don't "write an installer" you provide an existing installer (the package manager/package installer) with information about what to install where.
    - tokenizerrr 11y ago
      > The result of the work to create packages using the major packaging formats will produce a series of packages that combined, will arguably work better, on more distros than your home-grown installer. Plunking a binary in /usr/bin and some configuration files in /etc will work just about anywhere. > What makes you think creating e.g. a debian package equates to "writing a specific installer". The whole point of packages is that you don't "write an installer" you provide an existing installer (the package manager/package installer) with information about what to install where. You will probably write a script to build your package, right? That's writing an installer. Or a builder for an installer, or however you want to call it. The point is that you now have to do work for every distro you want to support, and all users without a package manager that you support is SOL.
      - stephenr 11y ago
        > Plunking a binary in /usr/bin and some configuration files in /etc will work just about anywhere. 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? If your software is literally so simple as files in /usr/bin and /etc, building packages to install those files should be easier than writing a good install script, because the package manager will handle so many use-cases for you out of the box. > You will probably write a script to build your package, right? 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. None of this is writing an installer unless you consider a makefile having an "install" target "writing an installer". > The point is that you now have to do work for every distro you want to support If the installation is as simple as you claim, the packages will be simple wrappers around the results of a makefile. If its more complex, then packages are still easier to maintain, because you don't need to worry about "what distro am i on, and do i need to check what the apache binary is called, or what packages are installed by default". > and all users without a package manager that you support is SOL. 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.
        tokenizerrr 11y ago
        > 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.
lmm 11y ago
LSB-compliant RPMS, though there are a few aggressively antisocial distributions that don't support them as well as they should.
- ape4 11y ago
  I just want to add my agreement to this. If the LSB (Linux Standard Base) was better supported these hacks would not be necessary.
rkeene2 11y ago
AppFS :-)

Could you point me to the better way of installing software that will work on all Linux distros?

stephenr 11y ago

District-appropriate packages. Use the right fucking tool for the job.

tokenizerrr 11y ago
That will not work on all Linux distros. That is writing a specific installer for each distro, which does not satisfy my requirements and as such is not the right tool for the job.
- stephenr 11y ago
  > That will not work on all Linux distros The result of the work to create packages using the major packaging formats will produce a series of packages that combined, will arguably work better, on more distros than your home-grown installer. > That is writing a specific installer What makes you think creating e.g. a debian package equates to "writing a specific installer". The whole point of packages is that you don't "write an installer" you provide an existing installer (the package manager/package installer) with information about what to install where.
  - tokenizerrr 11y ago
    > The result of the work to create packages using the major packaging formats will produce a series of packages that combined, will arguably work better, on more distros than your home-grown installer. Plunking a binary in /usr/bin and some configuration files in /etc will work just about anywhere. > What makes you think creating e.g. a debian package equates to "writing a specific installer". The whole point of packages is that you don't "write an installer" you provide an existing installer (the package manager/package installer) with information about what to install where. You will probably write a script to build your package, right? That's writing an installer. Or a builder for an installer, or however you want to call it. The point is that you now have to do work for every distro you want to support, and all users without a package manager that you support is SOL.
    - stephenr 11y ago
      > Plunking a binary in /usr/bin and some configuration files in /etc will work just about anywhere. 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? If your software is literally so simple as files in /usr/bin and /etc, building packages to install those files should be easier than writing a good install script, because the package manager will handle so many use-cases for you out of the box. > You will probably write a script to build your package, right? 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. None of this is writing an installer unless you consider a makefile having an "install" target "writing an installer". > The point is that you now have to do work for every distro you want to support If the installation is as simple as you claim, the packages will be simple wrappers around the results of a makefile. If its more complex, then packages are still easier to maintain, because you don't need to worry about "what distro am i on, and do i need to check what the apache binary is called, or what packages are installed by default". > and all users without a package manager that you support is SOL. 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.
      - tokenizerrr 11y ago
        > 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.

lmm 11y ago

LSB-compliant RPMS, though there are a few aggressively antisocial distributions that don't support them as well as they should.

ape4 11y ago
I just want to add my agreement to this. If the LSB (Linux Standard Base) was better supported these hacks would not be necessary.

rkeene2 11y ago

AppFS :-)