On Sun, Jan 20, 2013 at 11:06:25AM -0300, Antonio Terceiro wrote: > No we don't. ruby-rails-3.2 already depends on bundler. Fair enough. > 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. I suppose we would take care of the second-level dependencies when packaging the direct ones. Is that right? > > 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. Sorry, which question are you replying to? The latter, about CCing debian-ruby on a regular RFS? > > 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. I will contact upstream and ask for his current and future approach. My original idea was to create a gitlab-bundle package, containing the modified libraries which would be installed separately from the rest. Then, gitlab would use these modified ones instead of the original ones. This way, there'd be no conflicts. But it would be very messy, and an extra load of work for us. -- Daniel Martí - mvdan@mvdan.cc - GPG 0x58BF72C3
Attachment:
pgp0hC2xg_DCa.pgp
Description: PGP signature