On Wed, Jul 09, 2014 at 10:30PM, Roman Shaposhnik wrote: > On Wed, Jul 9, 2014 at 3:12 PM, Andrew Purtell <[email protected]> wrote: > > I wonder if relocatable DEBs are possible. (Some quick googling suggests > > not?) If not, relocatable RPMs would be a substantial amount of work for a > > half measure. > > Truly relocatable DEBs are next to impossible. However, after having a chance > to deal with this issue back at Cloudera, I'm now firmly convinced that > somebody > asking for relocatable packages is typically asking for two things: > #1 be able to install different versions of the same package side-by-side > #2 be able to install under a common subtree (such as /opt/our/hadoop) > > In both of these cases, the package ends up being treated as a glorifies > tarball. Why? Well, because: > * pre/post install scriplets are downright *dangerous* in those scenarious > * you have to do all the hooks to /etc/init.d &co manually anyway > * you can't really use the goodness of yum repos & such. > > If packages indeed are treated as a glorified tarballs -- what's wrong with > dpkg -x pkg.deb /path and rpm2cpio pkg.rpm | cpio -i --make-directories ?
Yup, that's exactly how I can do a make-shift gateway node on Ubuntu using only RPMs ;) So, yea - I think relocatable RPMs are pain, with no clear gain. However, the patches are welcome! ;) Cos > > I also think that if looking for deployment vehicles supporting concurrent > > installation of multiple component versions, we'd be better served putting > > project energy into LXC based deployment management and packaging. (That > > could be _really_ interesting, if for example containers have a late binding > > on dependencies, where they ask other containers during boot and service > > discovery to supply them with packages to install... I know, a crazy idea, > > not meant to lead this discussion off on a tangent) > > Very much +1 to that! At Pivotal (being a home of a world renowned PaaS) > we're looking into exactly that. A combination of Docker/LXC and OSv > containerized deployments that you can 'bake' on the fly provide for > some exciting opportunities. All of this, of course, comes at a price of > breaking a traditional CM (Puppet, etc.) model of classical deployment. > > Anyway, if there's a subset of folks who are interested in the next. gen > deployment approaches (especially for ephemeral Hadoop clusters) > I'd love to organize a meetup/pow-wow on that subject. > > Thanks, > Roman.
