I would personally just make one archive per distribution.
This would fix your issue, and would have the benefit that each archive would be smaller. (faster to download and parse by clients)
In a strict sense a binary file is one which is not character encoded as human readable text. More colloquially, a "binary" refers to a file that is compiled, executable code, although the file itself may not be executable (referring not so much to permissions as to the capacity to be run alone; some binary code files such as libraries are compiled, but regardless of permissions, they cannot be executed all by themselves). A binary which runs as a standalone executable is an "executable", although not all executable files are binaries (and this is about permissions: executable text files which invoke an interpreter via a shebang such as #!/bin/sh are executables too).
What is a binary package?
A binary package in a linux context is an application package which contains (pre-built) executables, as opposed to source code.
Note that this does not mean a package file is itself an executable. A package file is an archive (sort of like a .zip) which contains other files, and a "binary" package file is one which specifically contains executables (although again, executables are not necessarily truly binaries, and in fact binary packages may be used for compiled libraries which are binary code, but not executables). However, the package must be unpacked in order for you to access these files.
Usually that is taken care of for you by a package management system (e.g. apt/dpkg) which downloads the package and unpacks and installs the binaries inside for you.
What is diference between binary package and deb package?
There isn't -- .deb packages are binary packages, although there are .debs which contain source instead, these usually have -src appended to their name.
I run some direct package which is in "xyz.linux.run" format What are these package?
Those are generally self-extracting binary packages; they work by embedding a binary payload into a shell script. "Self-extracting" means you don't have to invoke another application (such as a package manager) in order to unpack and use them. However, since they do not work with a package manager, resolving their dependencies may be more of a crapshoot and hence some such packages use statically linked executables (they have all necessary libraries built into them) which wastes a bit of memory when they are used.
Best Answer
Using different branches is one approach, and I can suggest edits for @mestia’s answer if it seems appropriate (but read on...).
Another approach is to keep different files side-by-side; see Solaar for an example of this.
But both of these approaches have a significant shortcoming: they’re unsuitable for packages in Debian or Ubuntu (or probably other derivatives). If you intend on getting your package in a distribution some day, you should package it in such a way that the same set of files produces the correct result in the various distributions.
For an example of this, have a look at the Debian packaging for Solaar (full disclosure: I did the packaging).
The general idea is to ask
dpkg-vendorwhat the distribution is; so for Solaar, which has different dependencies in Debian and Ubuntu,debian/ruleshasand further down an override for
dh_gencontrolto fill in “substvars” as appropriate:This fills in the appropriate variables in
debian/control:and
You can use the test in
debian/rulesto control any action you can do in a makefile, which means you can combine this with alternative files and, for example, link the appropriate files just before they’re used in the package build.