3 ms·
Maybe because creating custom deb packages can be a hair-pulling experience? But this is our flow too. We have a jenkins job that builds our master branch and
by secondcoming 6y ago
Maybe because creating custom deb packages can be a hair-pulling experience?
But this is our flow too. We have a jenkins job that builds our master branch and uploads deb packages to jfrog. And then another to create a GCP image with these psckages, and a third to actually deploy these images to GCE. Containers are used for the various jenkins jobs, but not on the actual GCE instances.
- regularfry 6y agoIt depends which tooling layer you're using, really. If you're just saying "bundle up these files and put them on that part of the filesystem" it can be extremely simple. If you're trying to provide the full build-from-source chain... less so. Being able to ignore the Debian Packaging Guidelines is the path to sanity. In a previous incarnation I wrote https://github.com/regularfry/au https://github.com/regularfry/au to take the grunt-work out of packaging up ruby apps, and pretty much all it does is generate the minimum set of files that `dpkg-deb` needs to spit out an archive.
- debiandev 6y agoDebian Developer here. Reminder: the Debian Packaging Guidelines are meant for official Debian packages. Making a package with dpkg-deb -b <dir> <packagename> is very easy and gives all the features of APT (dependency tracking, config management, atomic deployment).
- secondcoming 6y agoYes, dpkg-deb is a recent discovery. Out of interest, what am I losing by doing it this way rather than if I followed the official guidelines?
- regularfry 6y agoYep. If you're packaging for Debian, the packaging guidelines make sense. If you're packaging something nobody outside your org is ever going to see, you can be a lot more flexible.