www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Binary compatibility on Linux

reply Jacob Carlborg <doob me.com> writes:
What's the best way to achieve binary compatibility on Linux? For 
example, if I compile an application on, say Ubuntu 12.04, it will most 
likely not run on any older versions of Ubuntu but it will run on future 
versions.

My current approach to solve this is to compile the application in the 
oldest version of Ubuntu I can find, in this case 6.x. This is starting 
to get a bit problematic:

* The integration with VirtuaBox (I'm running Ubuntu as a guest) is 
pretty bad
* DMD won't run of out of the box, I need to compile it. This is also 
making DVM basically useless
* I can't clone the dlang repositories due to having a very old version 
of git installed
* I can't compile git, I haven't investigated in why but probably due to 
the system is too old

Is there some compiler/linker flags I can use when building to make the 
executable compatibility with older versions of Linux?

Or is there a better way to solve this?

-- 
/Jacob Carlborg
Nov 10 2012
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 10.11.2012 16:40, schrieb Jacob Carlborg:
 What's the best way to achieve binary compatibility on Linux? For
 example, if I compile an application on, say Ubuntu 12.04, it will most
 likely not run on any older versions of Ubuntu but it will run on future
 versions.

 My current approach to solve this is to compile the application in the
 oldest version of Ubuntu I can find, in this case 6.x. This is starting
 to get a bit problematic:

 * The integration with VirtuaBox (I'm running Ubuntu as a guest) is
 pretty bad
 * DMD won't run of out of the box, I need to compile it. This is also
 making DVM basically useless
 * I can't clone the dlang repositories due to having a very old version
 of git installed
 * I can't compile git, I haven't investigated in why but probably due to
 the system is too old

 Is there some compiler/linker flags I can use when building to make the
 executable compatibility with older versions of Linux?

 Or is there a better way to solve this?

I guess the right answer is to have everything compiled statically, especially if you need compatibility across distributions. -- Paulo
Nov 10 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-10 18:39, Paulo Pinto wrote:

 I guess the right answer is to have everything compiled statically,
 especially if you need compatibility across distributions.

I just read somewhere that compiling it statically will make it _less_ compatible than compiling it dynamically. http://stackoverflow.com/questions/8657908/deploying-yesod-to-heroku-cant-build-statically/8658468#8658468 -- /Jacob Carlborg
Nov 10 2012
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 10.11.2012 19:54, schrieb Jacob Carlborg:
 On 2012-11-10 18:39, Paulo Pinto wrote:

 I guess the right answer is to have everything compiled statically,
 especially if you need compatibility across distributions.

I just read somewhere that compiling it statically will make it _less_ compatible than compiling it dynamically. http://stackoverflow.com/questions/8657908/deploying-yesod-to-heroku-cant-build-statically/8658468#8658468

Oh, the wonder of Linux based systems. :(
Nov 10 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 10 November 2012 17:39, Paulo Pinto <pjmlp progtools.org> wrote:
 Am 10.11.2012 16:40, schrieb Jacob Carlborg:

 What's the best way to achieve binary compatibility on Linux? For
 example, if I compile an application on, say Ubuntu 12.04, it will most
 likely not run on any older versions of Ubuntu but it will run on future
 versions.

 My current approach to solve this is to compile the application in the
 oldest version of Ubuntu I can find, in this case 6.x. This is starting
 to get a bit problematic:

 * The integration with VirtuaBox (I'm running Ubuntu as a guest) is
 pretty bad
 * DMD won't run of out of the box, I need to compile it. This is also
 making DVM basically useless
 * I can't clone the dlang repositories due to having a very old version
 of git installed
 * I can't compile git, I haven't investigated in why but probably due to
 the system is too old

 Is there some compiler/linker flags I can use when building to make the
 executable compatibility with older versions of Linux?

 Or is there a better way to solve this?

I guess the right answer is to have everything compiled statically, especially if you need compatibility across distributions. -- Paulo

Or ship the binary with it's dependencies all together as one package. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 10 2012
prev sibling next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Sat, 10 Nov 2012 16:40:37 +0100
schrieb Jacob Carlborg <doob me.com>:

 What's the best way to achieve binary compatibility on Linux? For 
 example, if I compile an application on, say Ubuntu 12.04, it will
 most likely not run on any older versions of Ubuntu but it will run
 on future versions.
 
 My current approach to solve this is to compile the application in
 the oldest version of Ubuntu I can find, in this case 6.x. This is
 starting to get a bit problematic:
 
 * The integration with VirtuaBox (I'm running Ubuntu as a guest) is 
 pretty bad
 * DMD won't run of out of the box, I need to compile it. This is also 
 making DVM basically useless
 * I can't clone the dlang repositories due to having a very old
 version of git installed
 * I can't compile git, I haven't investigated in why but probably due
 to the system is too old
 
 Is there some compiler/linker flags I can use when building to make
 the executable compatibility with older versions of Linux?
 
 Or is there a better way to solve this?
 

crosstool-NG has a nice option "Oldest supported ABI" where you can enter an old GLIBC version and the compiler will generate executables compatible with this version (although it still uses a recent glibc). I have no idea how this works, but that's the best solution I have seen so far. (crosstool also has an option "Disable symbols versioning" which completely disables versioning. quite cool). Here are some links which might help: http://sourceware.org/ml/libc-help/2011-04/msg00032.html http://www.trevorpounds.com/blog/?tag=symbol-versioning
Nov 10 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-10 19:54, Johannes Pfau wrote:

 crosstool-NG has a nice option "Oldest supported ABI" where you
 can enter an old GLIBC version and the compiler will generate
 executables compatible with this version (although it still uses a
 recent glibc). I have no idea how this works, but that's the best
 solution I have seen so far. (crosstool also has an option "Disable
 symbols versioning" which completely disables versioning. quite cool).

 Here are some links which might help:
 http://sourceware.org/ml/libc-help/2011-04/msg00032.html
 http://www.trevorpounds.com/blog/?tag=symbol-versioning

I got the last link from someone in the D IRC channel. I just don't know how to do that with D. -- /Jacob Carlborg
Nov 10 2012
prev sibling next sibling parent reply Jordi Sayol <g.sayol yahoo.es> writes:
Al 10/11/12 16:40, En/na Jacob Carlborg ha escrit:
 What's the best way to achieve binary compatibility on Linux? For example, if
I compile an application on, say Ubuntu 12.04, it will most likely not run on
any older versions of Ubuntu but it will run on future versions.
 
 My current approach to solve this is to compile the application in the oldest
version of Ubuntu I can find, in this case 6.x. This is starting to get a bit
problematic:
 
 * The integration with VirtuaBox (I'm running Ubuntu as a guest) is pretty bad
 * DMD won't run of out of the box, I need to compile it. This is also making
DVM basically useless
 * I can't clone the dlang repositories due to having a very old version of git
installed
 * I can't compile git, I haven't investigated in why but probably due to the
system is too old
 
 Is there some compiler/linker flags I can use when building to make the
executable compatibility with older versions of Linux?
 
 Or is there a better way to solve this?
 

Ubuntu 10.04.4 LTS is old enough? You can install/run dmd out of the box on it just installing the appropriate deb package. -- Jordi Sayol
Nov 10 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-10 19:49, Jordi Sayol wrote:

 Ubuntu 10.04.4 LTS is old enough?

I have no idea. I don't know how often people update their Linux systems and how compatible different distributions are. Sine I'm not using Linux as my primary platform I was hoping someone else could answer this. What is the oldest system I need to reasonably support? I'm mostly talking about tools and libraries for the D community here. -- /Jacob Carlborg
Nov 10 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-10 20:17, Robert wrote:
 I would say supporting distributions which are no longer supported by
 the distributions itself is of very little value. So for Ubuntu the last
 still supported LTS version should be old enough.

 I think virtually nobody is using anything older, especially not 06.XX!
 And if they do, then they will have a whole bunch of other problems than
 not being able to use your program.

I just picked the 6.x version to be sure it was compatible with everything else. You say the latest LTS, but the LTS are supported for five years. Don't they release new LTS more often than that? According to this https://wiki.ubuntu.com/LTS They release a new LTS every two years and they're supported for five years. If I pick Ubuntu 12.04, which is the latest LTS, they still support 10.04 until 2013. -- /Jacob Carlborg
Nov 10 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-10 22:14, eskimo wrote:

 I am sorry. I haven't quite said what I meant. I meant: The oldest still
 supported LTS of course :-)

That makes more sense. -- /Jacob Carlborg
Nov 11 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-10 20:10, 1100110 wrote:

 Oldest system to reasonably support?  I would say Debian Stable.
 It is used on a lot of server systems and isn't *too* far behind/old.

How compatible is Debian with non-debian based distributions? -- /Jacob Carlborg
Nov 11 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-11 23:30, 1100110 wrote:

 I've used alien a fair number of times, and its usually "just worked."
 Here is an FAQ:
 http://www.debian.org/doc/manuals/debian-faq/ch-compat.en.html
 That link provides a lot of info.

 Honestly, unless Ubuntu has done something really weird, Debian should
 be just as compatible with non-Debian distros as Ubuntu is.  Give me a
 solid example of what you mean and I'll take a closer look.

I'm not saying it's incompatible, I'm asking :) BTW, I actually don't know how compatible Ubuntu either.
 Ubuntu has a Debian-for-Ubuntu-Devs page.
 https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers
 That should explain something at least.

I guess I'll to take a look at that page.
 How does Debian Stable compare to Ubuntu 8.04(Hardy Heron) LTS which
 loses support in April?
 I'm not entirely sure.  http://packages.ubuntu.com/hardy/
 http://packages.debian.org/stable/

As I understand it Debian is a more stable distribution and Ubuntu is a faster moving target. The question is how much faster. Would Ubuntu LTS be more ahead of compared to the latest stable Debian. -- /Jacob Carlborg
Nov 11 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-14 19:20, John Colvin wrote:

 Debian testing is a rolling distribution, so it is always in an unstable
 state. Debian stable is, as it says, stable. To answer your question,
 just look at what debain version the particular ubuntu LTS version is
 based on.

Good point, how can I do that?
 To be honest, unless you're going to package all your dependancies along
 with the download, then you have to go down one of two routes: source
 distribution with a nice simple build procedure or making packages for
 the main distributions. I would recommend doing both.

I do provide source distribution. Not much of distribution, it's always available on Github. But I have one tool, DVM, which is a tool for installing D compilers and it's also written in D. It's a bit of a chicken-and-egg-problem. Sure you can get D compiler in other ways. But I think this tool in particular is very convenient to have available as a pre-built executable. A read a bit about creating packages for Debian, it seemed complicated and that I need to use stupid tools like Make. I hate Make.
 Look at it this way: the sort of people who aren't using a debian or
 fedora based distro aren't going to be phased by building from source
 (as a matter of fact they might prefer it).
 If you provide packages for debian and fedora and a source distribution
 as a fallback then you've covered the vast majority of your bases,
 allowing less advanced users to use package managers and letting the
 wild-west fringe distro people do whatever they want.

-- /Jacob Carlborg
Nov 14 2012
parent reply Thomas Koch <thomas koch.ro> writes:
Jacob Carlborg wrote:

 On 2012-11-14 19:20, John Colvin wrote:
 
 Debian testing is a rolling distribution, so it is always in an unstable
 state. Debian stable is, as it says, stable. To answer your question,
 just look at what debain version the particular ubuntu LTS version is
 based on.

Good point, how can I do that?

Ubuntu versions are not based on Debian _releases_. Ubuntu has an ever repeating development circle of half a year. At the beginning of the circle they take a snapshot of Debian unstable[1] and in the next months they mold this snapshot in an ubuntu release. [1] http://www.debian.org/releases To answer your question: There might be moments, directly after the release of a Debian stable version, when Ubuntu LTS is older then Debian. And after an LTS release the current Debian stable is surely older.
 To be honest, unless you're going to package all your dependancies along
 with the download, then you have to go down one of two routes: source
 distribution with a nice simple build procedure or making packages for
 the main distributions. I would recommend doing both.

I do provide source distribution. Not much of distribution, it's always available on Github. But I have one tool, DVM, which is a tool for installing D compilers and it's also written in D. It's a bit of a chicken-and-egg-problem. Sure you can get D compiler in other ways. But I think this tool in particular is very convenient to have available as a pre-built executable. A read a bit about creating packages for Debian, it seemed complicated and that I need to use stupid tools like Make. I hate Make.

You're right about make. However the Makefiles that one needs today for Debian packages are so trivial that it's not worth to worry about it. The most basic debian/rules (which is a Makefile) looks like: #!/usr/bin/make -f %: dh $ You only need to add additional targets if you want to override default actions. In that case you usually add simple targets with a few lines. We could switch from Makefiles to something else but it's simply not worth the effort. But after all you don't need to do the Debian packaging yourself. It's even a bit infamous if upstream is also the maintainer of the Debian package for different reasons. Just be a good upstream[2] and find a Debian maintainer who cares about your software. The same thing for Fedora. [2] wiki.debian.org/UpstreamGuide Regards, Thomas Koch
Nov 14 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-15 08:51, Thomas Koch wrote:

 You're right about make. However the Makefiles that one needs today for
 Debian packages are so trivial that it's not worth to worry about it. The
 most basic debian/rules (which is a Makefile) looks like:

                 #!/usr/bin/make -f
                 %:
                         dh $ 

 You only need to add additional targets if you want to override default
 actions. In that case you usually add simple targets with a few lines.

 We could switch from Makefiles to something else but it's simply not worth
 the effort.

Well, I simply don't think Makefiles are worth the effort.
 But after all you don't need to do the Debian packaging yourself. It's even
 a bit infamous if upstream is also the maintainer of the Debian package for
 different reasons. Just be a good upstream[2] and find a Debian maintainer
 who cares about your software. The same thing for Fedora.

It's not thinking about making the actual Debian package, I was more thinking of building the actual software.
 [2] wiki.debian.org/UpstreamGuide

I've read that page and from my understanding they prefer to use "make": "Please don't use SCons" "Using waf as build system is discouraged" -- /Jacob Carlborg
Nov 15 2012
next sibling parent reply Thomas Koch <thomas koch.ro> writes:
Russel Winder wrote:

 On Thu, 2012-11-15 at 10:35 +0100, Jacob Carlborg wrote:
 […]
 [2] wiki.debian.org/UpstreamGuide

I've read that page and from my understanding they prefer to use "make": "Please don't use SCons" "Using waf as build system is discouraged"

Comments made by people who are steeped in Autoconf/Automake and haven't actually used more modern systems such as SCons or Waf. The comments on the website are almost, but not quite, totally wrong on all important points.

period. If you found points you disagree with I'd love to see a comment added. I for example don't know either SCons or Waf. Maybe the information in our UpstreamGuide is not up to date anymore. Have you found more issues with the text? It would be interesting for us to listen to the opinions of non-debian members. Regards, Thomas Koch
Nov 15 2012
parent Thomas Koch <thomas koch.ro> writes:
Russel Winder wrote:

 [[I suspect this is getting way off-topic for this list, so if
 instructed to take it elsewhere will be happy to do so as long as
 elsewhere is defined.]]

I added your comments and a remark about the role of make in Debian: http://wiki.debian.org/UpstreamGuide?action=diff&rev1=58&rev2=59 I'd invite you to continue this discussion on debian-devel lists.debian.org (no subscription required). The UpstreamGuide is an important document for the "public relations" of Debian, so I'd like to get it right. Regards, Thomas Koch
Nov 16 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-15 17:23, Russel Winder wrote:

 Comments made by people who are steeped in Autoconf/Automake and haven't
 actually used more modern systems such as SCons or Waf.

 The comments on the website are almost, but not quite, totally wrong on
 all important points.

I'm not saying that they're right or wrong. I'm saying that they're there and it's obviously someones opinion. It also indicates that something that doesn't use Makefiles is not accepted or harder to get accepted. -- /Jacob Carlborg
Nov 15 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-10 20:10, 1100110 wrote:

 Oldest system to reasonably support?  I would say Debian Stable.
 It is used on a lot of server systems and isn't *too* far behind/old.

How would Debian Stable compare to, say, a five year old Ubuntu LTS that is still supported? -- /Jacob Carlborg
Nov 11 2012
prev sibling next sibling parent 1100110 <0b1100110 gmail.com> writes:
On Sat, 10 Nov 2012 13:01:27 -0600, Jacob Carlborg <doob me.com> wrote:

 On 2012-11-10 19:49, Jordi Sayol wrote:

 Ubuntu 10.04.4 LTS is old enough?

I have no idea. I don't know how often people update their Linux systems and how compatible different distributions are. Sine I'm not using Linux as my primary platform I was hoping someone else could answer this. What is the oldest system I need to reasonably support? I'm mostly talking about tools and libraries for the D community here.

Oldest system to reasonably support? I would say Debian Stable. It is used on a lot of server systems and isn't *too* far behind/old. If you need newer versions of packages, debian has its testing and experimental branches. I don't remember if they still are, but Ubuntu used to take a snapshot of Debian Sid to base its packages on. Linux Mint Debian gets its packages from debian testing I believe. The point I'm making is that Debian is pretty much the upstream repo. You can go as far as to test versions that haven't made it into Ubuntu or Mint yet. If people are using older versions than Debian Stable, then you should probably forget about them. Either they will cherry-pick the versions they need, or they are not interested in anything new and untested. Just my two cents as an ex server admin.
Nov 10 2012
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
I would say supporting distributions which are no longer supported by
the distributions itself is of very little value. So for Ubuntu the last
still supported LTS version should be old enough.

I think virtually nobody is using anything older, especially not 06.XX!
And if they do, then they will have a whole bunch of other problems than
not being able to use your program.

Best regards,

Robert

On Sat, 2012-11-10 at 20:01 +0100, Jacob Carlborg wrote:
 On 2012-11-10 19:49, Jordi Sayol wrote:
 
 Ubuntu 10.04.4 LTS is old enough?

I have no idea. I don't know how often people update their Linux systems and how compatible different distributions are. Sine I'm not using Linux as my primary platform I was hoping someone else could answer this. What is the oldest system I need to reasonably support? I'm mostly talking about tools and libraries for the D community here.

Nov 10 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Saturday, 10 November 2012 at 19:15:28 UTC, 1100110 wrote:
 If people are using older versions than Debian Stable, then you 
 should probably forget about them.
 Either they will cherry-pick the versions they need, or they 
 are not interested in anything new and untested.

 Just my two cents as an ex server admin.

This seems like a reasonable policy to me as well. David
Nov 10 2012
prev sibling next sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
Al 10/11/12 21:18, En/na Jacob Carlborg ha escrit:
 On 2012-11-10 20:17, Robert wrote:
 I would say supporting distributions which are no longer supported by
 the distributions itself is of very little value. So for Ubuntu the last
 still supported LTS version should be old enough.

 I think virtually nobody is using anything older, especially not 06.XX!
 And if they do, then they will have a whole bunch of other problems than
 not being able to use your program.

I just picked the 6.x version to be sure it was compatible with everything else. You say the latest LTS, but the LTS are supported for five years. Don't they release new LTS more often than that? According to this https://wiki.ubuntu.com/LTS They release a new LTS every two years and they're supported for five years. If I pick Ubuntu 12.04, which is the latest LTS, they still support 10.04 until 2013.

From Ubuntu 12.04 (April 2012), LTS has 5 years of support for Desktop and
server versions. Before this, LTS for Desktop has 3 years support, so the last
Ubuntu Desktop still supported is 10.04 (April 2010) and will finish in April
2013.

-- Jordi Sayol
Nov 10 2012
prev sibling next sibling parent eskimo <jfanatiker gmx.at> writes:
 
 You say the latest LTS, but the LTS are supported for five years. Don't 
 they release new LTS more often than that? According to this 
 https://wiki.ubuntu.com/LTS They release a new LTS every two years and 
 they're supported for five years.

I am sorry. I haven't quite said what I meant. I meant: The oldest still supported LTS of course :-) Also there are very few desktop users using such an old version, so if you don't target server systems, you might even relax your requirements further. But with the oldest still supported LTS release you are pretty much on the safe side. Best regards, Robert
Nov 10 2012
prev sibling next sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
From Ubuntu 12.04 (April 2012), LTS has 5 years of support for Desktop and
server versions. Before this, LTS for Desktop has 3 years support, so the last
Ubuntu Desktop still supported is 10.04 (April 2010) and will finish in April
2013.
 

s/last/oldest/ -- Jordi Sayol
Nov 10 2012
prev sibling next sibling parent reply Thomas Koch <thomas koch.ro> writes:
Jacob Carlborg wrote:

 What's the best way to achieve binary compatibility on Linux? For
 example, if I compile an application on, say Ubuntu 12.04, it will most
 likely not run on any older versions of Ubuntu but it will run on future
 versions.

The best way is to get your software in the official debian archive. There are infrastructure and established workflows to recompile packages for each Debian version. The backports archive contains newer versions of a package for the current stable Debian release. Is the software in question free software? It's not that hard to get software in Debian. Have a look at http://wiki.debian.org/UpstreamGuide Regards, Thomas Koch
Nov 11 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-11 10:30, Thomas Koch wrote:

 The best way is to get your software in the official debian archive. There
 are infrastructure and established workflows to recompile packages for each
 Debian version.
 The backports archive contains newer versions of a package for the current
 stable Debian release.

I don't want to limit myself to just the debian based package mangers. I want my tools to be available/usable on all distributions. -- /Jacob Carlborg
Nov 11 2012
parent Thomas Koch <thomas koch.ro> writes:
Jacob Carlborg wrote:

 On 2012-11-11 10:30, Thomas Koch wrote:
 
 The best way is to get your software in the official debian archive.
 There are infrastructure and established workflows to recompile packages
 for each Debian version.
 The backports archive contains newer versions of a package for the
 current stable Debian release.

I don't want to limit myself to just the debian based package mangers. I want my tools to be available/usable on all distributions.

If your package is in Debian then it is automatically also in Ubuntu, Mint, Xandros, Univention, Aptosid, Knoppix and a few douzend more distributions which are all derivatives of Debian: http://wiki.debian.org/Derivatives/Census http://www.debian.org/misc/children-distros Roughly the other half(?) of the linux universe is based on Fedora, e.g. CentOS, Red Hat: https://fedoraproject.org/wiki/Derived_distributions So by getting your package in the archives of Debian and Fedora, you should serve the large majority of linux users. The Debian wiki has a list of advantages why somebody would want to have his software in a distributions archive: http://wiki.debian.org/AdvantagesForUpstream Best regards, Thomas Koch
Nov 11 2012
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 11/11/2012 11:57 AM, Thomas Koch wrote:
 So by getting your package in the archives of Debian and Fedora, you should
 serve the large majority of linux users.

Which is well and good, but doesn't address the problem that software developers face, which is "How can I make directly available binaries of my programs that will work for any Linux user?" It's useful to be able to do that regardless of whether your software is FOSS and regardless of whether or not it's in distro repositories, because your latest release will always take time to propagate to the distros and because not everyone is comfortable compiling from source.
Nov 11 2012
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 11/11/2012 01:19 PM, Nick Sabalausky wrote:
 I'm not a Linux expert, but I'm fairly certain the answer is "You
 can't". Linux is very good at a lot of things, but standardization is
 definitely not one of them. Linux is just far too divergent ("herding
 cats" comes to mind) for a widely-compatible binary to be realistic.
 The best that can be done is make a dead-simple-to-use script to grab
 dependencies (isolated from the rest of the system if need be) and
 compile.

I think you're most likely right -- at least, it's impossible in the general case if not perhaps for a narrow band of widely-used distros. It's just that I think people were answering a different question from that which the OP asked, and I think his actual question deserves a decent answer (even if it's a negative one).
Nov 11 2012
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 2012-11-11 at 07:19 -0500, Nick Sabalausky wrote:
[=E2=80=A6]
 I'm not a Linux expert, but I'm fairly certain the answer is "You
 can't". Linux is very good at a lot of things, but standardization is
 definitely not one of them. Linux is just far too divergent ("herding
 cats" comes to mind) for a widely-compatible binary to be realistic.
 The best that can be done is make a dead-simple-to-use script to grab
 dependencies (isolated from the rest of the system if need be) and
 compile.

There is only one Linux, well except that they keep evolving it and changing the version number. Linux is very standardized in that there is only one. There is no Linux divergence as there was UNIX divergence. There are many, many, Linux-based distributions. The compilers vary, the version of Linux varies, the libraries vary, the packaging system varies. Binary compatibility across all of these is clearly impossible. This is not a problem, this is the antithesis of problem, as long as you allow the platform packagers to package or ship source and a build specification. Hence aptitude, yum, Waf and such stuff. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Nov 11 2012
prev sibling parent "Kagamin" <spam here.lot> writes:
On Sunday, 11 November 2012 at 11:46:07 UTC, Joseph Rushton 
Wakeling wrote:
 Which is well and good, but doesn't address the problem that 
 software developers face, which is "How can I make directly 
 available binaries of my programs that will work for any Linux 
 user?"

http://en.wikipedia.org/wiki/Open_Build_Service ?
Nov 13 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sun, 11 Nov 2012 12:45:56 +0100
Joseph Rushton Wakeling <joseph.wakeling webdrake.net> wrote:

 On 11/11/2012 11:57 AM, Thomas Koch wrote:
 So by getting your package in the archives of Debian and Fedora,
 you should serve the large majority of linux users.

Which is well and good, but doesn't address the problem that software developers face, which is "How can I make directly available binaries of my programs that will work for any Linux user?"

I'm not a Linux expert, but I'm fairly certain the answer is "You can't". Linux is very good at a lot of things, but standardization is definitely not one of them. Linux is just far too divergent ("herding cats" comes to mind) for a widely-compatible binary to be realistic. The best that can be done is make a dead-simple-to-use script to grab dependencies (isolated from the rest of the system if need be) and compile.
 It's useful to be able to do that regardless of whether your software
 is FOSS and regardless of whether or not it's in distro repositories,
 because your latest release will always take time to propagate to the
 distros and because not everyone is comfortable compiling from source.

Nov 11 2012
prev sibling next sibling parent 1100110 <0b1100110 gmail.com> writes:
On Sun, 11 Nov 2012 04:45:48 -0600, Jacob Carlborg <doob me.com> wrote:

 On 2012-11-10 20:10, 1100110 wrote:

 Oldest system to reasonably support?  I would say Debian Stable.
 It is used on a lot of server systems and isn't *too* far behind/old.

How compatible is Debian with non-debian based distributions?

I've used alien a fair number of times, and its usually "just worked." Here is an FAQ: http://www.debian.org/doc/manuals/debian-faq/ch-compat.en.html That link provides a lot of info. Honestly, unless Ubuntu has done something really weird, Debian should be just as compatible with non-Debian distros as Ubuntu is. Give me a solid example of what you mean and I'll take a closer look. Ubuntu has a Debian-for-Ubuntu-Devs page. https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers That should explain something at least. How does Debian Stable compare to Ubuntu 8.04(Hardy Heron) LTS which loses support in April? I'm not entirely sure. http://packages.ubuntu.com/hardy/ http://packages.debian.org/stable/
Nov 11 2012
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 12 November 2012 at 07:22:04 UTC, Jacob Carlborg wrote:

 As I understand it Debian is a more stable distribution and 
 Ubuntu is a faster moving target. The question is how much 
 faster. Would Ubuntu LTS be more ahead of compared to the 
 latest stable Debian.

Debian testing is a rolling distribution, so it is always in an unstable state. Debian stable is, as it says, stable. To answer your question, just look at what debain version the particular ubuntu LTS version is based on. To be honest, unless you're going to package all your dependancies along with the download, then you have to go down one of two routes: source distribution with a nice simple build procedure or making packages for the main distributions. I would recommend doing both. Look at it this way: the sort of people who aren't using a debian or fedora based distro aren't going to be phased by building from source (as a matter of fact they might prefer it). If you provide packages for debian and fedora and a source distribution as a fallback then you've covered the vast majority of your bases, allowing less advanced users to use package managers and letting the wild-west fringe distro people do whatever they want.
Nov 14 2012
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-11-15 at 10:35 +0100, Jacob Carlborg wrote:
[=E2=80=A6]
 [2] wiki.debian.org/UpstreamGuide

I've read that page and from my understanding they prefer to use "make": =20 "Please don't use SCons" "Using waf as build system is discouraged"

Comments made by people who are steeped in Autoconf/Automake and haven't actually used more modern systems such as SCons or Waf. The comments on the website are almost, but not quite, totally wrong on all important points. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Nov 15 2012
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

[[I suspect this is getting way off-topic for this list, so if
instructed to take it elsewhere will be happy to do so as long as
elsewhere is defined.]]

On Thu, 2012-11-15 at 17:52 +0100, Thomas Koch wrote:
[=E2=80=A6]
 The "website" is a wiki site edited by many people over a longer time=20
 period. If you found points you disagree with I'd love to see a comment=

 added.

"Please don't use SCons: we will have to re-implement many standard features of autoconf/automake, including DESTDIR, out of tree builds, cleaning and more." This just shows that the Debian system is so rooted in Autoconf/Automake that the mindset is to oppose anything that isn't. SCons supports out of tree builds far better than Autoconf/Automake. SCons supports cleaning far better than Autoconf/Automake, just differently. What is this "more"? Why is DESTDIR so important? SCons has good ways of doing installation, just differently. The problem here is that Debian gives no guidance to people who want to use SCons how to write their SCons builds to be harmonious with the Debian way of doing things. Instead the Debian system says "we are Autoconf/Autotools, so don't use SCons".=20 "Using waf as build system is discouraged. One of the reasons is the recommendation to ship a waf executable in every single package using it, instead of using a system wide one. Also note that just shipping the waf executable (which contains a binary blob) is considered to be not complient with the Debian Free Software guidelines by the FTP Team. Please see #645190 and UnpackWaf for more details on the issue and how to avoid it, if you have to use waf." It is true that Thomas pushes the "carry the build system with the project" line. In fact Gradle has done something along these lines as well. Indeed SCons supports this way of working. In a global context, it is a very good idea, even if it is conflict with the Debian way of working. But like SCons, Waf works very well with an installed Waf, the project supplied Waf can be ignored. The Waf executable is not a binary blob really, it is just an encoded source distribution which has to be decoded. If the people had investigated properly this comment would just not have been made. Actually the comments on the indicated issue explain this very clearly. Sadly other comments wilfully misrepresent the status quo.
 I for example don't know either SCons or Waf. Maybe the information in ou=

 UpstreamGuide is not up to date anymore.

To be honest, the comments never were reasonable, they were founded on prejudice and lack of research. If the instructions were "We like Autotools/Automake and are not prepared to work with anything else." it would be more acceptable as being opinionated, honest, and a statement to people how Debian worked. This would be far more acceptable/better than the FUD that is there.
 Have you found more issues with the text? It would be interesting for us =

 listen to the opinions of non-debian members.

I am a Debian Unstable user and fan. I hate Autotools/Automake. Therefore I do not get involved in building packages for Debian, I am just a freeloading user, total fretard ;-) I have though been known to build packages and put them in my own repository. I'm sometimes selfish like that :-)=20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Nov 15 2012
prev sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-11-15 at 20:42 +0100, Jacob Carlborg wrote:
[=E2=80=A6]
 I'm not saying that they're right or wrong. I'm saying that they're=20
 there and it's obviously someones opinion. It also indicates that=20
 something that doesn't use Makefiles is not accepted or harder to get=20
 accepted.

I just submitted a email on this which I think answers the point. I worry that it is way off-topic for this list though. The summary is that Debian is Autotools/Automake focussed and any other build is a problem for them. I think this is sad, but it is Debian's privilege to be dictatorial on this for the Debian repository. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Nov 15 2012