Rob Halförd - (Gridcoin), on 28 Dec 2014 - 3:30 PM, said:
I am considering RPMs and distros, but given the track record of not one person successfully volunteering to compile linux on a Mac more than once per year, I dont think creating 4 binaries daily is actually realistic. Until I actually see the results appearing and building and md5'ing and linking and running. (In contrast, SeP and Sec have been building daily).
Next, we have to have to a mechanism in the coin to allow exchanges to build the coin and check in the source and make it opensource anyway; otherwise exchanges will not run it; so this step is pretty much necessary either way. What you are pointing out is the difference between me hiding future code releases from everyone and not hiding the source (as checking it in reveals the source that the config manager will be using to build the rpms every night).
Anyway, my main point is, in order for gridcoin to succeed I feel the last resort will have to be binary distros as people will always wonder whats in the code, and with binary distros you do have to support a much wider range of platforms than 3 - its more like 2 compiled versions per flavor; more like 15 distros (thats why most of these ftp sites have a full page of binaries). If we miss a distro, the user cant run the coin at all.
So for this step Im homogenizing the key requirement for exchanges or end linux users down to an organization name + public key. If the key is abused or compromised we can ban it in the next release. If the whole system is compromised we will either have to fix the system or move to the distros. But my effort now is to keep the source open at this point.
I like the idea, but I also understand Rob's very true observation.
Yes I know it can be automated, I have package repos for employees and myself, I also oversee the management of others internal ones for companies I have contracts with.
The point is that you need to decide what the minimum common denominator you are willing to support (which is the least amount of distros) and then create Package Dev machine (virtual or not) that are pure clean vanilla, but also fully updated with all the dev tools needed and keep them that way.
Need to know how to properly clean build and package works.
Be willing to report, support and fix any problem in the various steps, keeping good proper practice.
Most can be scripted, but still need some maintenance and attention... basically knowledge and time or money.
If we can maybe get a dedicated serious and reliable package maintainer we could give it a shot.
also I don't think we need the windows packaging system Chocolatey, since windows is already packaged with the installer; I would vote as you for the .deb and .rpm, and maybe .tgz.
The only thing is the choice of distro to support: I would go first on the serious users first, therefore CentOS and straight Debian maybe CoreOS since those are the one that are the most used on headless servers and clouds by pros and then Slackware, Ubuntu, Fedora, OpenSUSE for the second tiers.
I am trying to make it easy and still appeal to the most and disgruntle none: CenOS is basically RedHat Enterprise without the price and strings, which is where all the .rpm distros came from (fedora is only the free community edition of the RedHat home/workstation so no really server material); Debian on the other side of the server spectrum is the serious choice, where all the other .deb distros come from, including Ubuntu, not the other way around... even if Ubuntu LTS Server could be considered, it has less of an professional user help base to go to, compared to Debian, if there are any problems.
For .tgz you then could add Slackware (yes probably very publicized, but many very very important servers run on it, when you need ultimate flexibility and uninterrupted up time in the 500+ days, that is where you go, like... guess what... world DNSes, infrastructure, routing, firewall, etc.)... Slackware is one of the very first and the best distro... but you really need to know what you are doing and where... Basically that is if you are really serious and an hardcore Unix admin... so with no offense, I would leave Slackware last, when we get the other two working.
P.S.: I also vote to keep the source open at the same time... the packaging is only as a service to make it easy for the linux users community, maybe a marketing pitch point and once trusted, for the exchanges; Especially with hash and signature... I would put mine if package is built and system is maintained by me.