> I'm not sure why it's the author's responsibility to go setup a dozen different VMs
To make sure it compiles and works under dozen different distributions (in practice centos + ubuntu/debian usually cover most cases). If you don't test it, how do you know it's usable at all? Besides, as long as you don't invent some crazy custom build system, the only thing you really have to write is metadata and dependencies (rules file can be 3 lines long for autotools software).
Also, this way you can just push your software to a build farm like launchpad ppa and let them do the dirty work. If you include self-contained tests with the sources, you can even run them after the build to verify correctness for that environment. This is much better than doing it by hand.
Also keep in mind that the first person to deploy your software automatically to a couple of places will either use your/distro's package or will have to make their own. Building from source works only for one-person uncontrolled environment.
Please add FreeBSD to the list of OS's you use for testing of compilation.
You have no idea how frustrating it is to have an open source project claim to run on unix like operating systems and not compile correctly on FreeBSD or Mac OS X...
As much as I agree... I'm not sure how much it's worth the effort until someone points out that your project definitely doesn't work. Even looking at silly stats like: http://distrowatch.com/stats.php?section=popularity - covering one popular rpm and one deb distribution, you're covering majority already (with only slight modifications if necessary). Mac users will expect their own packages anyways and you can't run Mac OSX legally without owning the hardware, which many developers don't own.
Regarding FreeBSD... lack of any good result in the first 3 pages of "freebsd packaging guide" search should explain a lot.
Generally if it compiles on FreeBSD it compiles on Mac OS X, at least that has been my experience in the past. I am in the unique position that I develop on Mac OS X, then do my tests on FreeBSD and when it works on those attempt it on Linux.
The counter-argument is that testing on more platforms tends to expose bugs that it's worth fixing because they would have affected you anyway, you just didn't know it yet.
Ok - I wasn't clear on that one. I know they're called ports and would probably look for stuff like port creation / porting / port-something-else. Yet, it seems a bit weird to me that looking for freebsd packaging guide doesn't give you anything even remotely useful. (consider some developer who has a couple hours to spend, thinks about making a freebsd port, looks for packaging information and concludes that it's not even documented / not worth learning right now)
Imagine I'm your average, workaday software developer.
If I've written some software to scratch a personal itch and I push it out to github because I reckon someone, somewhere might benefit at some arbitrary future point, or to show off to a future employer, or whatever, then I really do not care about making sure it compiles and works on a dozen distributions. Just getting it working to fix my problem, then publishing it, ticks all the boxes I'm interested in. After all, I've got fifteen other problems I need to solve this week, none of which involve spooling up VMs for distributions I never use.
If a packager then decides that their favourite distro would benefit from having my code packaged nicely, at what point does that become my responsibility? It Works For Me(tm), and beyond reviewing and applying patches other people might send me to improve it, I don't necessarily have any interest whatsoever in what happens outside my repository as long as it doesn't stop the code from solving my problem. It's possible that I might be both developer and packager for a distribution or two, but that's the exception, not the rule.
Personally, I think the right way is for a clear path from language-package to distro-package to be provided by my environment such that I don't have to think about it, and I think that the bulk of that responsibility should be shouldered by the distro - but it's insane to think that the language environment shouldn't help, because there is a mutual benefit there. I think we're nearly there with RVM and rubygems, but that's about as far from autotools as you can get.
Comments
> I'm not sure why it's the author's responsibility to go setup a dozen different VMs
To make sure it compiles and works under dozen different distributions (in practice centos + ubuntu/debian usually cover most cases). If you don't test it, how do you know it's usable at all? Besides, as long as you don't invent some crazy custom build system, the only thing you really have to write is metadata and dependencies (rules file can be 3 lines long for autotools software).
Also, this way you can just push your software to a build farm like launchpad ppa and let them do the dirty work. If you include self-contained tests with the sources, you can even run them after the build to verify correctness for that environment. This is much better than doing it by hand.
Also keep in mind that the first person to deploy your software automatically to a couple of places will either use your/distro's package or will have to make their own. Building from source works only for one-person uncontrolled environment.
Please add FreeBSD to the list of OS's you use for testing of compilation.
You have no idea how frustrating it is to have an open source project claim to run on unix like operating systems and not compile correctly on FreeBSD or Mac OS X...
As much as I agree... I'm not sure how much it's worth the effort until someone points out that your project definitely doesn't work. Even looking at silly stats like: http://distrowatch.com/stats.php?section=popularity - covering one popular rpm and one deb distribution, you're covering majority already (with only slight modifications if necessary). Mac users will expect their own packages anyways and you can't run Mac OSX legally without owning the hardware, which many developers don't own.
Regarding FreeBSD... lack of any good result in the first 3 pages of "freebsd packaging guide" search should explain a lot.
Generally if it compiles on FreeBSD it compiles on Mac OS X, at least that has been my experience in the past. I am in the unique position that I develop on Mac OS X, then do my tests on FreeBSD and when it works on those attempt it on Linux.
The counter-argument is that testing on more platforms tends to expose bugs that it's worth fixing because they would have affected you anyway, you just didn't know it yet.
search for "freebsd porting guide".
Ok - I wasn't clear on that one. I know they're called ports and would probably look for stuff like port creation / porting / port-something-else. Yet, it seems a bit weird to me that looking for freebsd packaging guide doesn't give you anything even remotely useful. (consider some developer who has a couple hours to spend, thinks about making a freebsd port, looks for packaging information and concludes that it's not even documented / not worth learning right now)
In FreeBSD to create a package you create a portfile, the packages come free at that point ...
But I understand your concern.
try using openbsd sometime... :)
Imagine I'm your average, workaday software developer.
If I've written some software to scratch a personal itch and I push it out to github because I reckon someone, somewhere might benefit at some arbitrary future point, or to show off to a future employer, or whatever, then I really do not care about making sure it compiles and works on a dozen distributions. Just getting it working to fix my problem, then publishing it, ticks all the boxes I'm interested in. After all, I've got fifteen other problems I need to solve this week, none of which involve spooling up VMs for distributions I never use.
If a packager then decides that their favourite distro would benefit from having my code packaged nicely, at what point does that become my responsibility? It Works For Me(tm), and beyond reviewing and applying patches other people might send me to improve it, I don't necessarily have any interest whatsoever in what happens outside my repository as long as it doesn't stop the code from solving my problem. It's possible that I might be both developer and packager for a distribution or two, but that's the exception, not the rule.
Personally, I think the right way is for a clear path from language-package to distro-package to be provided by my environment such that I don't have to think about it, and I think that the bulk of that responsibility should be shouldered by the distro - but it's insane to think that the language environment shouldn't help, because there is a mutual benefit there. I think we're nearly there with RVM and rubygems, but that's about as far from autotools as you can get.