Hi Alex, Sorry for the long delay to answer. Alex Young escreveu: > On 09/09/12 20:15, Antonio Terceiro wrote: > >In the case of Noosfero, my main reason for sticking with Debian > >packages is being able to manage not only Ruby dependencies, but also > >non-Ruby ones, like apache, varnish, memcached, PostgreSQL, etc, etc, > >using a single mechanism. > > > > So are *all* the ruby dependencies for Noosfero available as Debian > packages in Wheezy, or do you run a local apt repository to fill in > the gaps? Noosfero was not ported to Wheezy yet, but all its dependencies on Squeeze come straight from Debian. Ideally that should also be the case for Wheezy (the porting work is just starting). That said, I must admit that we cheat a little, since there are some dependencies that are embedded in Noosfero VCS repository and therefore come together with the whole thing. That is one of the reasons why Noosfero was not uploaded to Debian proper yet. > That's an approach I could certainly appreciate, but if that *is* the > recommended approach then it could possibly use a write-up :-) I'm afraid there is no single recommended approach, unless you are talking about getting a Rails app in Debian proper (in which case the approach is having all dependencies properly packaged and them making the app use them). > I'm also interested in how you square this with development using > bundler, which doesn't respect system-provided gems. Is there any > way at the moment to go from `bundle package` to having a > Wheezy-compatible apt repository that doesn't clash with > Wheezy-provided gems? For those of us not (yet) developing on > Wheezy, this is a particularly relevant point. Wheezy (and Rails 3) porting is just starting, so I don't know yet how exactly that is going to be. On Wheezy bundler is able to detect Debian-installed packages, so ideally there should be no issues. But you never know. > >In the end, this issue boils down to the old debate of whether you > >should rely on system packages or if you should do it yourself (or rely > >on third-party automation scripts etc). Both approaches have advantages > >and drawbacks, which I won't rehash here. > > I think it's inevitable in any interestingly-sized project that > there will be dependencies which *can't* come from system-provided > packages, and it's handling that boundary which is confusing. Sure. > >Another important point for me is targetting a known-stable base system, > >with well-known versions of all the components (i.e. Debian stable, or > >Ubuntu LTS, or ...), versus having to worry about incompatibilities > >between different versions of each of them. > > > That's a persuasive argument, but it does inevitably lead to > problems where a non-packaged dependency becomes incompatible over > time and security patches (or just bug fixes) stop coming to the > last version you can use. Once you decide to add non-packaged components to the system, you might end up alone in the dark, for the simple reason that the combination might not have been tested by anyone before (specially in the case of a recent component on an old system). If a reasoable amount of other people also do that, they might help each other, if only you do it, it's all on you. -- Antonio Terceiro <terceiro@debian.org>
Attachment:
signature.asc
Description: Digital signature