Etcher: Our BinTray RPM (redhat / fedora) setup is wrong

[lurch]

Splitting this separate issue out from #1752
(apologies in advance if some of the terminology I use below isn't quite right!)

It looks like deb repositories have the concept of devel and stable package lists ("distributions"), and a user can choose (via their sources.list file) whether they want to use the stable or devel distribution (note the mention of stable here ). We publish production releases (1.1.0, 1.1.2, etc.) of the etcher-electron _package_ into the etcher _component_ of the stable _distribution_, and we publish snapshot releases (1.1.2+8aa58a7, 1.1.2+78fdc5b, etc.) of the etcher-electron _package_ into the etcher-devel _component_ of the devel _distribution_.
Therefore (AIUI) a user with deb https://dl.bintray.com/resin-io/debian stable etcher in their sources.list (or sources.list.d/etcher.list) will always be upgraded to the latest production version of the etcher-electron package, and a user with deb https://dl.bintray.com/resin-io/debian devel etcher-devel in their sources.list will always be upgraded to the latest snapshot version of the etcher-electron package.
(pinging @dlech as he helped us with our initial Debian packaging ( #747 ), so he can probably point out any mistakes I've made :wink: )

However rpm repositories don't seem to have this distinction between different distributions or components, so even though we have separate etcher and etcher-devel components in https://bintray.com/resin-io/redhat , because these components both have packages named etcher-electron, when a user follows our instructions to install etcher-electron on Redhat or Fedora, they always get the latest snapshot version installed, rather than the latest production version installed! (see this happening in #1752 )
(pinging @Dark-Passenger as he helped us with our initial Redhat packaging ( #1425 ), so he can probably point out any mistakes I've made :wink: )

If my theory is correct (further research & testing in VM images is needed), I _think_ the way to fix this would be to instead have separate redhat and redhat-devel repositories on BinTray (with production releases published to the former, and snapshot releases published to the latter), instead of publishing both production and snapshot releases to the same redhat repository...?

[Dark-Passenger]

@lurch yup RPM packages need different repositories for different channels. I would also like to suggest maybe not calling it devel the whole meaning of a devel package is header files or stuff needed to build the package, maybe beta or testing would be better ?

[lurch]

I would also like to suggest maybe not calling it devel the whole meaning of a devel package is header files or stuff needed to build the package

Hmmm, that's a good point. Seems like the etcher-devel stuff was added in #1611

@dlech What are the 'typical' Debian-conventions here around naming of snapshot and production components / distributions?

@jviotti As we've not 'advertised' these snapshot (devel) components yet (it's only the production components that we've been mentioning in https://github.com/resin-io/etcher#installers ), I think there'd be no backwards-compatibility problems if we decided to rename our snapshot components and/or distributions?

[dlech]

Debian has a similar concept of development packages that have a -dev suffix. Official Debian doesn't do beta channels. When I do Ubuntu PPAs for other things that I maintain, I have a separate PPA for the stable and development channels. But, I have seen other projects that just use different component names like we are doing here (for example, the mono project has alpha and beta components). So, there probably isn't a "usual" way for Debian based distros to do development snanapshots.

[lurch]

Thanks for the info @dlech
AFAICT, we're currently using both a different _distribution_ and a different _component_ for production vs. snapshot releases (for Debian). I guess it might be "neater" to just have the same _component_ within different _distributions_? Hmmm, but then I guess that https://bintray.com/resin-io/debian might look 'messy' if we have both production and snapshot releases in the same _component_, as bintray doesn't appear to separate things by _distribution_ . So perhaps the status-quo (but merely renaming the 'devel' parts) would be better... (alternatively I guess another option would be to have both etcher-beta and etcher _components_ withing the same stable _distribution_ - but that might also be confusing)

Current state

• Debian

| Release type | repo URL | distribution | component | package(s) |
| --- | --- | --- | --- | --- |
| production | https://resin-io.bintray.com/debian | stable | etcher | etcher-electron |
| snapshot | https://resin-io.bintray.com/debian | devel | etcher-devel | etcher-electron |

• Redhat

| Release type | repo URL | component (gets ignored) | package(s) |
| --- | --- | --- | --- |
| production | https://resin-io.bintray.com/redhat | etcher | etcher-electron |
| snapshot | https://resin-io.bintray.com/redhat | etcher-devel | etcher-electron |

Proposed state

• Debian

| Release type | repo URL | distribution | component | package(s) |
| --- | --- | --- | --- | --- |
| production | https://resin-io.bintray.com/debian | stable | etcher | etcher-electron |
| snapshot | https://resin-io.bintray.com/debian | beta | etcher-beta | etcher-electron |

• Redhat

| Release type | repo URL | component (gets ignored) | package(s) |
| --- | --- | --- | --- |
| production | https://resin-io.bintray.com/redhat | etcher | etcher-electron |
| snapshot | https://resin-io.bintray.com/redhat-beta | etcher-beta | etcher-electron |

Would that work for everybody? @dlech @Dark-Passenger @jviotti @jhermsmeier

Once we've got this all sorted out, then it might be interesting to think about creating .deb and .rpm packages of the etcher-cli and publishing those in the above repos too :-)

[Dark-Passenger]

@lurch good approach but I have one issue.

1. the package names are different but the package is the same(app name ?) this basically means if I have etcher installed and then install beta it erases the package and installs beta, once I remove the beta I have a broken etcher install.

I think a better aproach for this would be to name the packages the same etcher. then the beta would basically upgrade the package and then if I uninstall the beta its basically me uninstalling etcher app.

This would remove the ambiguous relationship between the two packages and also allow me to downgrade to the older package by removing or disabling the beta repo and downgrading the package.

Note : this is related only to rpm packages, please correct me if I misunderstood the structure.

[lurch]

@Dark-Passenger I think you might have misunderstood what I've written? I'm afraid I don't really understand what you've written :confused:

What do you mean by "the package names are different but the package is the same" ? In the Redhat tables above, the component column is only for use by the https://bintray.com/resin-io/redhat webpage and allows us to visually separate the production releases from the snapshot releases. At the RPM-repo level, there would simply be a https://resin-io.bintray.com/redhat repo, containing packages named e.g. etcher-electron-1.1.2.x86_64.rpm which would install an etcher-electron executable; and a https://resin-io.bintray.com/redhat-beta repo containing packages named e.g. etcher-electron-1.1.2+acb4271.x86_64.rpm which would install an etcher-electron executable.

I think this might be what you mean by "a better aproach for this would be to name the packages the same etcher. then the beta would basically upgrade the package and then if I uninstall the beta its basically me uninstalling etcher app." ?

[Dark-Passenger]

Ah yes that makes sense and yes this should be perfect for rpm based systems.

[lurch]

The etcher-devel components have now been deleted from BinTray following #2076 which means this 'bug' is no longer present and so this issue can be closed :tada: