Packaging change to Debian/Ubuntu packages

Hi all,

The new packages worked well on Debian, however some unresolved issues
slipped the net for Ubuntu. Since we're unable to fix these quickly, I
have reverted to the old way of packaging Foreman (installing the gems
locally to vendor/) and pushed that to the stable repo. As such
Foreman 1.0-12 should now function on Ubuntu as normal.

We're looking at ways to improve the packaging, but I wanted to get
something out to you guys that actually works before I spend time
working on a better solution.

Sorry for the inconvenience in the last few days. We'll be doing
better testing on the Ubuntu packages going forward.

Greg

Just thought I'd throw my comments out on this real quick based on what I
have seen. (This is FriedBob on IRC, BTW)

With the current state of puppet 2.7x and Ruby 1.9.3 (ie, not playing nice
at all) having the vendor install for the gems is a better option, as it
will localize what is installed and not make them system wide.

The biggest side effect of this is that when foreman install rdoc 3.12, it
will NOT break puppet doc overall. The rake task to generate the
documentation and add in the extra links and validation will still fail,
but at least people will be able to generate the docs for their classes in
some manner.

I've been told that puppet 3 has full ruby 1.9.3 support, so this means
that the rdoc issue should be resolved in the next major puppet release.

I'm in the process of testing this, but ran into some snags which I will be
working with some of the puppet guys to resolve later this morning.

··· On Monday, August 6, 2012 4:54:27 PM UTC-5, Greg Sutcliffe wrote: > > Hi all, > > The new packages worked well on Debian, however some unresolved issues > slipped the net for Ubuntu. Since we're unable to fix these quickly, I > have reverted to the old way of packaging Foreman (installing the gems > locally to vendor/) and pushed that to the stable repo. As such > Foreman 1.0-12 should now function on Ubuntu as normal. > > We're looking at ways to improve the packaging, but I wanted to get > something out to you guys that actually works before I spend time > working on a better solution. > > Sorry for the inconvenience in the last few days. We'll be doing > better testing on the Ubuntu packages going forward. > > Greg >

A good point. After some discussion with Sam, we feel the way to
proceed right now is to produce a "libforeman" type package which will
have all the gems prebuilt for the OS in question, stored in
~foreman/vendor/cache. Bundler can then be told to use that cache. We
can also package the Gemfile.lock which will ensure it uses the
version in the cache.

This should keep the gems separate from the system, but also remove
the need for the gem-building dependencies (build-essential, gcc,
*-dev libs) which I feel we shouldn't be asking people to install on
production systems.

Right now we need to do some work on the foreman-installer modules to
bring it up to full 1.0 working/tested status, but I'll be returning
to the packaging after that.

Greg

··· On 7 August 2012 14:22, llowder wrote: > With the current state of puppet 2.7x and Ruby 1.9.3 (ie, not playing nice > at all) having the vendor install for the gems is a better option, as it > will localize what is installed and not make them system wide.

> > With the current state of puppet 2.7x and Ruby 1.9.3 (ie, not playing
> nice
> > at all) having the vendor install for the gems is a better option, as it
> > will localize what is installed and not make them system wide.
>
> A good point. After some discussion with Sam, we feel the way to
> proceed right now is to produce a "libforeman" type package which will
> have all the gems prebuilt for the OS in question, stored in
> ~foreman/vendor/cache. Bundler can then be told to use that cache. We
> can also package the Gemfile.lock which will ensure it uses the
> version in the cache.
>
> This should keep the gems separate from the system, but also remove
> the need for the gem-building dependencies (build-essential, gcc,
> *-dev libs) which I feel we shouldn't be asking people to install on
> production systems.
>
> Right now we need to do some work on the foreman-installer modules to
> bring it up to full 1.0 working/tested status, but I'll be returning
> to the packaging after that.
>
>
Can we open this stuff for a broader discussion, e.g. what about other
operating systems?
would it be possible to offer two package types? one that replace system
packages and the other that can co exists?

Ohad

··· On Wed, Aug 8, 2012 at 12:28 PM, Greg Sutcliffe wrote: > On 7 August 2012 14:22, llowder wrote:

Greg


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.

Sure, we can discuss other distros :slight_smile:

For Debian/Ubuntu, I think we will give ourselves pain going forward
with the system approach. Right now we have to downgrade ~5 packages
to get it to install on Ubuntu. Without really tight integration with
the upstream devs, this will just happen again and again. I definitely
want to talk to them about how to resolve it, but haven't had time to
reach out to them yet.

For other distros, I think we have to take it on a case-by-case
system. Each will have their own packaging format, and their own way
of handling rubygems. If we can use a system-gem approach on $distro
then great, but the vendor/cache is a useful fallback that should work
for any distro.

Debian/Ubuntu is an odd case since the same packages usually work on
both. If there's strong feeling for the system packages on Debian, and
vendor/cache packages on Ubuntu, we can do that. I'd rather not double
our testing overhead by offering both types for a single distro,
though, again, unless people feel strongly.

Greg

··· On 8 August 2012 10:33, Ohad Levy wrote: > Can we open this stuff for a broader discussion, e.g. what about other > operating systems? > would it be possible to offer two package types? one that replace system > packages and the other that can co exists?