Ok, done, you have convinced me, especially because we can now Depends on
ruby-foobar-X.Y (= ${source:Version}).Please check rails-4.0.git in pkg-ruby-extras (and uploaded to experimental to people to have something to play with). Antonio, could you please add support for -D<directory> to dh_ruby? I have created a quite ugly hack because of the lack of support for this switch. I will convert rails-3.2 to the same format when I have some energy again. And ... feel free to add yourself to Uploaders. (Please do... :)). O. On Mon, May 27, 2013 at 7:02 PM, Antonio Terceiro <[email protected]>wrote: > On Mon, May 27, 2013 at 09:20:22AM +0200, Ondřej Surý wrote: > > On Sat, May 25, 2013 at 12:37 AM, Antonio Terceiro <[email protected] > >wrote: > > > > > On Fri, May 24, 2013 at 06:52:39PM +0200, Ondřej Surý wrote: > > > > Ok, this suits me equally well (although I had to subscribe). > > > > > > > > Anyway I was thinking (along the way home from work) that we probably > > > > should provide only one version of rails in each Debian release (e.g. > > > move > > > > our problems to our downstream packages :)). > > > > > > > > We have only few downstream packages and it's not worth our time and > > > energy > > > > to keep two and more versions of rails just for one or two > > > r-dependencies. > > > > > > I agree. That, together with having a single source package for all of > > > the rails components, will drastically reduce our maintainance effort. > > > > > > > I still don't really see what's easier in bundling several tarballs into > > one big one, now that I untangled build-depends in all rails gems. > > > > You cannot get a bundled upstream tarball anywhere, so what's the point? > > I'm not suggesting we bundle several tarballs, but to use a single one > generated from the rails git repository directly. > > Other points that make me think it would be easier to have a single > rails source package: > > - All Rails security patches are distributed based on the git repo, so > we have to manually edit them to strip the first path component > before we include them in our split packages. It's not hard, but it's > boring and error prone. The larger the patch the worse. `quilt import > -pN` can help here, but unmodified patches are better. > > - when the security patch touches more than one component (not > uncommon), we have to do 2 security uploads intead of one. > > - All of the components are developed together and released in lockstep. > So if there is a security bug in say ActiveRecord, all others are also > released with a bumped version number anyway even if they were not > touched. > > - IMO because the components are released upstream in lockstep, having > them in Debian with different version numbers conis confusing. > > -- > Antonio Terceiro <[email protected]> > -- Ondřej Surý <[email protected]>
