5 ms·

> Install with native package tool I'm sad that so few people seem to build native OS packages for deployments. My build system creates a release package and s

> Install with native package tool I'm sad that so few people seem to build native OS packages for deployments. My build system creates a release package and sticks it in an apt repo, then puppet installs latest version of package when it runs.

AgentIcarus 13y ago
I've just started looking at this sort of thing - can I ask what technology you decided on for the apt repo? (I'm especially interested in whether the restriction most of them impose on having multiple versions of a package is something you are dealing with).
- Tobu 13y ago
  I use mini-dinstall for repos. Multiple versions would complicate things however; I'd probably do it by combining multiple suites.
- robinson-wall 13y ago
  Late reply, sorry. I went with reprepro to maintain my apt repo. It's nice, but has one major drawback which may be a showstopper, depending on your use case. It can only keep one version of a package at a time in each distribution.
rdtsc 13y ago
Second that. I think it only comes with maturity. If there is a small start-up and they have a couple of Ubuntu servers they'd start with just syncing their source repo, running 'make && make installs' by hand via ssh. After a while if they use python, node or ruby, maybe start generating language specific packages (pip, virtualenv, etc). Next phase is when the need for upgrade/downgrade transactions comes about, handling transitive dependencies (my package needs another package, which in turn requires a third package to be upgraded, which is a base system package to be upgraded). Now 'make && make install's looks silly and mess up the file system with left-over files. Deployment ssh scripts become a tangled mess and so on. Then slowly they think "It would be cool if there was a system created that can transitively handle package versions, and maybe provide transactions with pre and post install scripts". If they are lucky, someone will point them to apt or rpms or they'll write a broken version of those things from scratch.
deleted 13y ago
[deleted]
zmmmmm 13y ago
Would make your deployment system very OS dependent. All other things being equal, I would generally prefer to have a completely platform agnostic mechanism over something platform specific.

AgentIcarus 13y ago

I've just started looking at this sort of thing - can I ask what technology you decided on for the apt repo? (I'm especially interested in whether the restriction most of them impose on having multiple versions of a package is something you are dealing with).

Tobu 13y ago
I use mini-dinstall for repos. Multiple versions would complicate things however; I'd probably do it by combining multiple suites.
robinson-wall 13y ago
Late reply, sorry. I went with reprepro to maintain my apt repo. It's nice, but has one major drawback which may be a showstopper, depending on your use case. It can only keep one version of a package at a time in each distribution.

rdtsc 13y ago

Second that. I think it only comes with maturity. If there is a small start-up and they have a couple of Ubuntu servers they'd start with just syncing their source repo, running 'make && make installs' by hand via ssh. After a while if they use python, node or ruby, maybe start generating language specific packages (pip, virtualenv, etc). Next phase is when the need for upgrade/downgrade transactions comes about, handling transitive dependencies (my package needs another package, which in turn requires a third package to be upgraded, which is a base system package to be upgraded). Now 'make && make install's looks silly and mess up the file system with left-over files. Deployment ssh scripts become a tangled mess and so on. Then slowly they think "It would be cool if there was a system created that can transitively handle package versions, and maybe provide transactions with pre and post install scripts". If they are lucky, someone will point them to apt or rpms or they'll write a broken version of those things from scratch.

deleted 13y ago

[deleted]

zmmmmm 13y ago

Would make your deployment system very OS dependent. All other things being equal, I would generally prefer to have a completely platform agnostic mechanism over something platform specific.