> 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.

> 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.

> 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.

> 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.