bigtop-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <>
Subject Re: Generating Relocatable RPMS
Date Thu, 10 Jul 2014 05:30:12 GMT
On Wed, Jul 9, 2014 at 3:12 PM, Andrew Purtell <> 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 ?

> 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.


View raw message