#cloudsmith (2020-10)
Cloudsmith package management and hosting
2020-10-12
@Erik Osterman (Cloud Posse) has joined the channel
set the channel description: Cloudsmith package management and hosting
@Lee Skillen has joined the channel
@Lee Skillen so I’m looking at the next big initiative which is adding debian support for our cloudposse packages. Cloudsmith has the concept of “universal packages” (right name?) where you can generate the synthetic packages for any major distro.
In this mode, is it possible to upload packages to override the synthetic packages? e.g. we’ve had to make bug fixes for certain distros.
Yep, you can upload packages that are in all of the supported distribution indexes, for any release of those distributions. Although if you’re looking to create a derivative (forked, flavour, whatever you’d like to call it) package of something that exists, then it’s better to represent this in the versioning of the package (rather than it being identical to the upstream). This is how distributions, like Ubuntu, create Debian-derivative packages, but put an “ubuntu” spin on them: https://www.debian.org/doc/debian-policy/ch-controlfields.html#version
E.g. Imagine that sl at version 1.0.3-1 had an issue. You might create a new variant with a version of 1.0.3-1cp1 which would be semantically greater than 1.0.3-1 but (e.g.) less than 1.0.4-1. When a user goes to install sl from your repository, and 1.0.3-1 already exists alongside your fixed 1.0.3-1cp1 package, yours will be chosen.
So let me clarify, the binary would be identical to the upstream. What we’ve had to do is in the past, add different dependencies based on the OS release to satisfy things like dynamic linking (e.g. in alpine, sometimes we need to add libc6-compat but not always).
(we’re never forking / patching, only redistributing binaries)
Though I’m guessing we’ll have a lot less of these sort of issues once we move to a glibc os
Sure, although those are still changes to the package since the metadata is versioned alongside the content. If the user had the same version already, the local package manager wouldn’t fetch your modified version. Some Ubuntu packages (e.g.) are identical to the upstream too, and sometimes the changes are the same as you’ve proposed. Linkage changes. Upto you on how to manage it, of course!
So when you see sl @ 1.0.3-1ubuntu2 in the wild, it means the upstream version was 1.0.3 (i.e. the version of the package the source was built from), the Debian version is 1 (i.e. the first package version of 1.0.3 that Debian built and released), and the Ubuntu version is 2 (i.e. the second version of the package that Ubuntu built and released).
Looking forward to Debian-based packages though.
@Andriy Knysh (Cloud Posse) has joined the channel
@Stan M has joined the channel
@Matt Gowie has joined the channel
@Joe Niland has joined the channel
@MattyB has joined the channel
@Reinholds Zviedris has joined the channel
2020-10-13
@Kyle Harrison has joined the channel
@Andrew Speed has joined the channel
@Lee Skillen any idea what would cause this?
I’m trying out the any-version feature with alpine
Hi Erik, I work with Lee at Cloudsmith, I’ll take a look into this for you now
Thanks @Andrew Speed!
Here’s the command to reproduce:
docker run -it alpine:3.12 sh -c 'apk add curl bash; curl <https://cloudsmith.cloudposse.workers.dev/install.sh> | bash; apk add terraform-0.13@cloudposse'
Thanks very much Erik, I think we’ve identified the issue and are working on the fix now
Hi Erik, apologies for the delay, our fix is now live and looks like it should resolve the issue you were seeing.
Let us know if things are working as expected, or if you run into any other issues
Confirmed! It works for me now
Great to hear, but sorry for the inconvenience this caused. Give us a shout if you encounter any more issues and we’ll help get it resolved
For sure! About to merge our PR now to take advantage of this. Will reduce our builds from ~500 -> 100
@Tom Gibson has joined the channel