On Sun, Jan 20, 2013 at 01:34:51PM +0100, Daniel Martí wrote: > On Wed, Jan 16, 2013 at 06:21:47PM +0100, Cédric Boutillier wrote: > > > - There are quite a few ruby libraries that will need to be packaged for > > > Debian in order to get gitlab into our repos. I don't yet have an > > > exact number of new packages needed for 4.0.0, but it will probably be > > > well over a dozen packages. Will that be a problem? If not, how would > > > we manage so many sponsorship requests? > > > > I think it is not a problem. Could you please get a precise list of > > these missing packages? You should then send ITP/RFP bugs for each of > > these. Maybe someone will help and package some of them. > > After having a look at the ruby bundler docs, I still didn't know how to > get a precise list for it. Alexander suggested the following: > > % grep '^GEM' -A1000 Gemfile.lock |grep '^ [^ ]' > > Whose ouput is as follows: > [snip long list of gems] > > Of course, we must add bundler to the list. No we don't. ruby-rails-3.2 already depends on bundler. > Do you know of any better method to find all deps, including the > non-direct ones? You should be good by looking at the Gemfile itself. You don't need to include transitive dependencies. Just stick to the direct dependencies and assume that they have their dependencies sorted out. > > There is currently an effort to package diaspora, and they have the same > > problem. There has always been someone to review the packages and upload > > once ready, so this should be ok. Just send RFS email to the debian-ruby > > list. > > Ah, so there's no need to bother debian-mentors and > sponsorship-requests? Or do I just post a regular RFS with debian-ruby > as Cc? Yep. > > > - In gitlab's Gemfile, I can see where it needs some specific patched > > > libs in order to function. Thus, they would be of no use to any other > > > programs, which is why I don't know how to package them. Perhaps as > > > gitlab-libs? This is the bit that troubles me: > > > > > # GITLAB patched libs > > > gem "grit", git: "https://github.com/gitlabhq/grit.git";, ref: '7f35cb98ff17d534a07e3ce6ec3d580f67402837' > > > gem "omniauth-ldap", git: "https://github.com/gitlabhq/omniauth-ldap.git";, ref: 'f038dd852d7bd473a557e385d5d7c2fd5dc1dc2e' > > > gem 'yaml_db', git: "https://github.com/gitlabhq/yaml_db.git";, ref: '98e9a5dca43e3fedd3268c76a73af40d1bdf1dfd' > > > gem 'grack', git: "https://github.com/gitlabhq/grack.git";, ref: 'ba46f3b0845c6a09d488ae6abdce6ede37e227e8' > > > gem 'grit_ext', git: "https://github.com/gitlabhq/grit_ext.git";, ref: '8e6afc2da821354774aa4d1ee8a1aa2082f84a3e' > > > > > Most of the dependencies just require a minimum or specific version, > > > or even no specific version at all. These won't be a problem. But > > > gitlab's patched dependencies are not only specific to the package, > > > but are bound specific to a git ref as well. > > > > If they diverged too much, then you may need to package them separately > > indeed. Some of these patched libraries have departed very little from > > upstream (I just looked at yaml_db), so it might be possible to use the > > original ones? > > Even if they diverged very lightly with the original ones, I believe it > will be easier to package them separately. Since they are specific to > gitlab, I suggest we package them under a gitlab-* name. Any > suggestions? IMO this is very wrong. The best way to go forward would be to push those changes to the original upstream packages and have them packaged. Are the changes really specific to gitlab? Besides, if you package those modified versions they would have to conflict with packages of the original packages, which might create weird situations where $foo and gitlab cannot be co-installed. The best (and maybe only) way to achieve sane packaging is having a sane upstream. -- Antonio Terceiro <terceiro@debian.org>
Attachment:
signature.asc
Description: Digital signature