Hello Axilleas, On Mon, Aug 19, 2013 at 12:12:39 +0300, Axilleas Pipinellis wrote: > Hello team! Hope my reply will reach the correct thread... It did :) > My name is Axilleas Pipinellis, a student from Greece currently > involved in a GSoC project and that is to package GitLab for > Fedora[0]. > > I just found out you are making efforts to accomplish the same thing > for Debian, so I would like to share what I have done so far and if > possible to coordinate our efforts for a better upstream support. Sure! Thank you for getting in touch with us. > == Forked gems > > The only big stopper for now is the forked gems, as you already > know. From what I got by your discussion is that you are going to > patch the upstream gems with GitLab's forks. May I ask in what stage > this process is by now? As far as I know we're still busy packaging all the other gems. You can have a look at updated graphs here: http://people.debian.org/~boutil/gitlab/ Last one is broken, but this one is accurate: http://people.debian.org/~boutil/gitlab/gitlab_deps20130821.pdf > In Fedora there are some guidelines that state that "packaging forks > is fine as long as they are parallel installable and don't interfere > with each other." which unfortunately isn't the case with GitLab. So > either I will ask for a > > See a discussion about it in Fedora infra ML [1]. Yeah, our approach is quite similar. We cannot package their gems separately, so we thought that as long as the changes do not differ too much from their original counterparts, we could package them as a replacement. > I also compiled a list of the forked gems and their differences of > upstream [2], it may be of help. Thank you, much appreciated! > == What version of GitLab do you plan to support > > Given that a new one comes out every month and some gems may be > added or updated, there should be an ongoing process of packaging if > we want to have the latest version. I suppose we could focus on a stable release for the first package, and then work from that. If we are to change our objective every time a new release is out with new or different dependencies, we might not make it in some time. > Also, how do you plan to package GitLab itself? I mean how are you > going to follow the FHS? As far as I know all packages must, or at least should, follow it. So yes, that's what we'll do. > == Version mismatch > > This is also one big problem we have to encounter. There is the > upstream version, the one GitLab uses (may be pinned to an older > one), and then there is the distro's version. > > In Fedora we try to package the latest version but in the case of > GitLab that is not always the case [3]. > > Here [4] is a table of all these versions specifically compared to > Fedora (I compare with the devel repo named Rawhide). I compiled > this list by using this hacky method [5]. If that would be easy for > you to traverse the gems, I saved them in json format, see my github > repo [6]. > > What are your plans on this matter? I don't think there's any easy solution to this. Obviously what would be best is for upstream to keep his software up to date with the stable releases of its dependencies, but perhaps they cannot do so without some lag. Have you asked him about it? Another thing that comes to mind is that, if gitlab was to require versions of ruby lib X no newer than Y, that would mean that gitlab would be locking several packages from being updated. And that would not be good at all. In the simplest case, because another package might need newer versions. > == Testing GitLab with packaged gems > > How are you going to do this? I was thinking to remove one gem from > the Gemfile at a time and use the one I packaged instead and test if > that works. But that would require a lot of testing and time to do. Indeed it would. If you were confident enough you could replace them all at once and list bugs/errors as you found them, which could take less time if most of it was to work out of the box but could also be a nightmare if there are many issues to fix. > Or what my mentor suggested, maybe use "bundle install --local" > which prefers local gems instead of remote and also check on > bundler_ext[7], which tries to workaround some bundler issues with > rpm/deb packages. Sounds like a better idea. This would also concern replacing the gems by packaged libraries progressively, correct? > == Getting close to GitLab devs > > There is a campfire chat channel for GitLab contributors, maybe one > of you could request an invite as a representative. That way we > could talk on the fly and you could ask questions to devs directly. Sorry, what's a campfire chat channel? If they offered an official/developer IRC channel I'd join, but I haven't seen any yet. > That's all that comes to mind right now, if I think of something > else I'll let you know :) Hope we can work on this somehow. Again, thanks for getting in touch. Packaging gitlab will be easier if we can talk to each other and share our work. Regards. -- Daniel Martí - mvdan@mvdan.cc - GPG 0x4348041C
Attachment:
pgpbjkZATGQVS.pgp
Description: PGP signature