Hi! I would very much like to see gitlab in Debian. If you need help, sponsorship or want to co-maintain I would be happy to help out! >> 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? Yes, if they aren't already packaged. >> > 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? You can submit a regular RFS and Cc debian-ruby. >> > 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 agree fully with this. > 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. As Antonio said, the changes should go upstream. If they cannot I suggest to patch the already existing Debian package (or clean upstream to be packaged) so it supports whatever the fork supports (if it is sane). If things get complicated, discuss here. :-) I checked the Gemfile and made a very naive script to check if the required packages are packaged or not. The quick glance reports about 66 packages, heads up for false positives and negatives! Depending on if the developement group can be ommitted, it is eight packages less to package. (The development group is nine packages but I suggest sdoc is good to have in order to generate docs.) I am sorry to say that I am not too sure about Gemfiles but I suppose that the development, test group can be ommitted as well, that is another fifteen packages less. That would total in about 40 primary dependencies not yet packaged. I have attached the script and it's output. Maybe someone more knowledgable in Ruby and Gemfile land can take a peek at it? -- Per
Attachment:
gitlab-debian-missing-deps.sh
Description: Bourne shell script
Attachment:
gitlab.deb-deps
Description: Binary data