Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Our BinTray RPM (redhat / fedora) setup is wrong
See original GitHub issueSplitting 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 😉 )
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 😉 )
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…?
Issue Analytics
- State:
- Created 6 years ago
- Comments:8 (8 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Ah yes that makes sense and yes this should be perfect for rpm based systems.
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-betaandetchercomponents withing the samestabledistribution - but that might also be confusing)Current state
Proposed state
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
.deband.rpmpackages of theetcher-cliand publishing those in the above repos too 😃