On 08/08/2011 06:44 PM, Mo Morsi wrote:
We often patch the gem specs anyways to manipulate the dependencies
to
conform to the versions in Fedora [1] [2] [3]
Hey,
first of all I would like to put a remark of me writing about changing
an upstream Rails 3 project for easy deployment. You are writing about
general rules of Rails 3 apps packaging. We have slightly different
angle of view. But basically it's the same thing ;-)
I am not fun of generated patches. It seems these were created by
generating "correct" lockfile and diffing it against the one in the
upstream. This can be really painful process doing that for each Fedora
version. Once the upstream issues "bundle update" the patch is incorrect
and must be regenerated from scratch.
I understand there is no easy way of regenerating the lock file during
the RPM build, since we need all the dependencies installed as
BuildRequires. But isn't there better (or less painful) process for
that? I can hardly imagine manual updating such a patch.
So far we've been playing with:
a) Generating the lockfile using bundler in the SPEC file.
Pros:
- works without human intervention
Cons:
- the build environment must be rock solid
- we must take care during dependency upgrades
- each dep update = new app version release
b) Removing bundler from the app.
Pros:
- no bundler, no problem
Cons:
- can work only when the upstream project is Fedora-based
- we are changing the app (and possibly it's behavior)
- not there yet (too many requires missing)
c) Generating the lockfile each start
Pros:
- easy trick
- not changing the app
- works with upgrades or different library versions
Cons:
- start is a bit slower
d) Monkey-patching bundler just to ignore versions
Pros:
- the ruby way (?)
- pretty elegant
- fast start
- no lock file at all
Cons:
- it's a hack
- did not test it yet
e) Patching the lockfile for each Fedora version
Pros:
- not changing bundler or app itself
- no bundler during the build
- pretty standard process
Cons:
- more difficult to maintain
- must take care when updating Gemfile.lock in the upstream
I think your recommendation (e) could work for pretty stable projects
where dependencies does not change many often. For those which are in
the early stage I can picture this:
* The upstream team should keep the version numbers as close as possible
to the oldest supported Fedora in the git Gemfile.lock.
* The upstream team must keep the build environment clean & up-to-date
(e.g. using Koji). Outdated dependencies during the build lead to
incorrect release (wrong lock file).
* The upstream team should have automated tests installing each release
and checking bundler. If there is deviation found its corrected (using
bundler install) and diff is sent to the mailing list to put it in the
SPEC git repo.
If you have other best practices feel free to add them. I am trying to
collect if this approach (e) is feasible for us.
In any case, would you accept a rails 3 app taking (c) or (d) approach
to Fedora?
Many thanks
--
Later,
Lukas "lzap" Zapletal