{"thread":{"id":"16687","subject":"[RFC] cgit in git?","startedAt":"2008-12-11T21:48:45Z","lastAt":"2008-12-12T00:15:46Z","messageCount":7,"participants":["Lars Hjemli","Miklos Vajna","Jakub Narebski","Junio C Hamano","Johan Herland","Todd Zullinger"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"97625","messageId":"8c5c35580812111348iceaf30dyb55183017cff5b1d@mail.gmail.com","threadId":"16687","inReplyTo":null,"subject":"[RFC] cgit in git?","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2008-12-11T21:48:45Z","receivedAt":"2008-12-11T21:48:45Z","isPatch":false,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"Background: I've been asked by the fedora project how to package cgit.\nThe problem is basically that cgit is designed to be statically linked\nwith a specific git release (i.e. libgit.a and xdiff/lib.a).\n\nWhen manually building cgit from a tarball this isn't a problem:\n'make get-git' will download the required git sources from kernel.org.\nBut the buildsystem/policy used by the fedora project does not allow\nnetwork access during package builds, and since it is quite unlikely\nthat the git package always will match the exact release needed by the\ncgit package, I only see four options:\n1) the fedora project makes a 'git-for-cgit' package containing the\nneeded release of the git sources\n2) the cgit release tarballs includes the needed git sources\n3) the cgit sources are subtree-merged into git\n4) cgit is modified to link against libgit2\n\nOption 1 seems unlikely to happen since such a 'git-for-cgit' package\nwould basically require the fedora project to support two git\npackages.\n\nOption 2 is doable but still requires the fedora project to support\ntwo git packages (but now the 'git-for-cgit' package is hidden inside\nthe cgit source tree). The good thing about this option is that it\nonly requires some minor modifications to the cgit releases.\n\nOption 3 would solve the problem for the fedora project but is not for\nme to decide - it might become an extra maintenance burden on the git\nmaintainer and community.\n\nOption 4 is the correct solution but not a very practical one; it's\ncurrently hard to predict when libgit2 will be ready for general\n(c)git use.\n\nPersonally I'd love for option 3 to happen, hence this rfc.\n\n-- \nlarsh\n"},{"id":"97627","messageId":"20081211221540.GA5691@genesis.frugalware.org","threadId":"16687","inReplyTo":"8c5c35580812111348iceaf30dyb55183017cff5b1d@mail.gmail.com","subject":"Re: [RFC] cgit in git?","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-12-11T22:15:40Z","receivedAt":"2008-12-11T22:15:40Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Thu, Dec 11, 2008 at 10:48:45PM +0100, Lars Hjemli <hjemli@gmail.com> wrote:\n> 2) the cgit release tarballs includes the needed git sources\n> 3) the cgit sources are subtree-merged into git\n> 4) cgit is modified to link against libgit2\n> \n> Option 1 seems unlikely to happen since such a 'git-for-cgit' package\n> would basically require the fedora project to support two git\n> packages.\n> \n> Option 2 is doable but still requires the fedora project to support\n> two git packages (but now the 'git-for-cgit' package is hidden inside\n> the cgit source tree). The good thing about this option is that it\n> only requires some minor modifications to the cgit releases.\n\nI don't say 2) is the ideal solution (probably 4) will be), but that's\nwhat we choosed for Frugalware and I think Fedora could live with it as\nwell.\n"},{"id":"97629","messageId":"m3k5a6gxft.fsf@localhost.localdomain","threadId":"16687","inReplyTo":"8c5c35580812111348iceaf30dyb55183017cff5b1d@mail.gmail.com","subject":"Re: [RFC] cgit in git?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-12-11T22:28:21Z","receivedAt":"2008-12-11T22:28:21Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Lars Hjemli\" <hjemli@gmail.com> writes:\n\n> But the buildsystem/policy used by the fedora project does not allow\n> network access during package builds, and since it is quite unlikely\n> that the git package always will match the exact release needed by the\n> cgit package, I only see four options:\n> 1) the fedora project makes a 'git-for-cgit' package containing the\n> needed release of the git sources\n> 2) the cgit release tarballs includes the needed git sources\n\n2b) make cgit .spec use _two_ tarballs as a source, one with cgit\nsources, one with git sources.  This assumes that you always use\nreleased git version as a base.\n\nThis is immediate solution.\n\n> 3) the cgit sources are subtree-merged into git\n\nI wonder how likely this would be.\n\n> 4) cgit is modified to link against libgit2\n\nOption 4) would be probably best in long term, but libgit2 doesn't\nexists yet.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"97632","messageId":"7vwse6bart.fsf@gitster.siamese.dyndns.org","threadId":"16687","inReplyTo":"8c5c35580812111348iceaf30dyb55183017cff5b1d@mail.gmail.com","subject":"Re: [RFC] cgit in git?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-11T22:35:34Z","receivedAt":"2008-12-11T22:35:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Lars Hjemli\" <hjemli@gmail.com> writes:\n\n> 2) the cgit release tarballs includes the needed git sources\n>\n> Option 2 is doable but still requires the fedora project to support\n> two git packages (but now the 'git-for-cgit' package is hidden inside\n> the cgit source tree). The good thing about this option is that it\n> only requires some minor modifications to the cgit releases.\n\nI do not understand why this is any extra work for fedora.  Instead of\nrunning \"make get-git\" and then running your build procedure, they need to\njust run your build procedure because you now ship your source with the\nmatching version of the git source, which sounds like the right thing to\nme.  You do not install anything from the contained git.git area (we do\nnot do shared objects, nor public header files) to the end product, right?\n\nDoesn't cgit bind git.git as a subproject at the source level?  I would\nexpect that the most natural release tarball for such a project would be a\nsingle tarball that has both the superproject itself _and_ the submodules\nit contains already extracted, iow, the state of your tree after you run\n\"make get-git\".\n"},{"id":"97633","messageId":"200812112340.57223.johan@herland.net","threadId":"16687","inReplyTo":"8c5c35580812111348iceaf30dyb55183017cff5b1d@mail.gmail.com","subject":"Re: [RFC] cgit in git?","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2008-12-11T22:40:57Z","receivedAt":"2008-12-11T22:40:57Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Thursday 11 December 2008, Lars Hjemli wrote:\n> Background: I've been asked by the fedora project how to package cgit.\n> The problem is basically that cgit is designed to be statically linked\n> with a specific git release (i.e. libgit.a and xdiff/lib.a).\n>\n> When manually building cgit from a tarball this isn't a problem:\n> 'make get-git' will download the required git sources from kernel.org.\n> But the buildsystem/policy used by the fedora project does not allow\n> network access during package builds, and since it is quite unlikely\n> that the git package always will match the exact release needed by the\n> cgit package, I only see four options:\n> 1) the fedora project makes a 'git-for-cgit' package containing the\n> needed release of the git sources\n> 2) the cgit release tarballs includes the needed git sources\n> 3) the cgit sources are subtree-merged into git\n> 4) cgit is modified to link against libgit2\n>\n> Option 1 seems unlikely to happen since such a 'git-for-cgit' package\n> would basically require the fedora project to support two git\n> packages.\n>\n> Option 2 is doable but still requires the fedora project to support\n> two git packages (but now the 'git-for-cgit' package is hidden inside\n> the cgit source tree). The good thing about this option is that it\n> only requires some minor modifications to the cgit releases.\n>\n> Option 3 would solve the problem for the fedora project but is not for\n> me to decide - it might become an extra maintenance burden on the git\n> maintainer and community.\n>\n> Option 4 is the correct solution but not a very practical one; it's\n> currently hard to predict when libgit2 will be ready for general\n> (c)git use.\n>\n> Personally I'd love for option 3 to happen, hence this rfc.\n\nOption 5: Include cgit as a submodule in git.git. Then it's available to \nthose who want it, but not cloned/built by default.\n\nIf that doesn't pan out, I also support option #3.\n\nI've been a happy cgit user for a number of months, and have yet to find a \nsingle issue where cgit is not better than or equal to gitweb. I have \nnothing bad to say about gitweb per se, but cgit simply offers me a better \nuser experience, not least because of its blazing speed.\n\n\nHave fun!\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"97639","messageId":"8c5c35580812111537v1144c9fdy19f2a3cc56e2a04f@mail.gmail.com","threadId":"16687","inReplyTo":"7vwse6bart.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] cgit in git?","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2008-12-11T23:37:07Z","receivedAt":"2008-12-11T23:37:07Z","isPatch":false,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On Thu, Dec 11, 2008 at 23:35, Junio C Hamano <gitster@pobox.com> wrote:\n> \"Lars Hjemli\" <hjemli@gmail.com> writes:\n>\n>> 2) the cgit release tarballs includes the needed git sources\n>>\n>> Option 2 is doable but still requires the fedora project to support\n>> two git packages (but now the 'git-for-cgit' package is hidden inside\n>> the cgit source tree). The good thing about this option is that it\n>> only requires some minor modifications to the cgit releases.\n>\n> I do not understand why this is any extra work for fedora.\n\nI imagined that it could have a ripple-effect on package dependencies,\ni.e. the git release used by cgit could have subtle\n'incompatibilities' with the real git package, but I really don't know\nthe first thing about packaging so this is just a guess.\n\n\n> Instead of\n> running \"make get-git\" and then running your build procedure, they need to\n> just run your build procedure because you now ship your source with the\n> matching version of the git source, which sounds like the right thing to\n> me.  You do not install anything from the contained git.git area (we do\n> not do shared objects, nor public header files) to the end product, right?\n\nRight.\n\n\n> Doesn't cgit bind git.git as a subproject at the source level?  I would\n> expect that the most natural release tarball for such a project would be a\n> single tarball that has both the superproject itself _and_ the submodules\n> it contains already extracted, iow, the state of your tree after you run\n> \"make get-git\".\n\nYour expectation makes sense to me, thanks for elaborating.\n\nSeth: would such a self-contained tarball solve the problems on your end?\n\n--\nlarsh\n"},{"id":"97652","messageId":"20081212001546.GV13722@inocybe.teonanacatl.org","threadId":"16687","inReplyTo":"8c5c35580812111537v1144c9fdy19f2a3cc56e2a04f@mail.gmail.com","subject":"Re: [RFC] cgit in git?","fromName":"Todd Zullinger","fromEmail":"tmz@pobox.com","sentAt":"2008-12-12T00:15:46Z","receivedAt":"2008-12-12T00:15:46Z","isPatch":false,"sender":{"key":"tmz@pobox.com","avatar":"https://avatars.githubusercontent.com/u/806319?v=4"},"body":"Lars Hjemli wrote:\n> On Thu, Dec 11, 2008 at 23:35, Junio C Hamano <gitster@pobox.com>\n> wrote:\n>> Doesn't cgit bind git.git as a subproject at the source level?  I\n>> would expect that the most natural release tarball for such a\n>> project would be a single tarball that has both the superproject\n>> itself _and_ the submodules it contains already extracted, iow, the\n>> state of your tree after you run \"make get-git\".\n>\n> Your expectation makes sense to me, thanks for elaborating.\n> \n> Seth: would such a self-contained tarball solve the problems on your\n> end?\n\n(I'm not Seth, nor do I play him on TV -- though I have been offered\nhis role in a small town production of \"How the Grinch Stole\nChristmas\"... ;)\n\nThe downside to this is that cgit would be duplicating the git\nsources, and thus, so would any distribution packages.  If there is a\nbug in git, both the git and cgit packages would need to be updated to\nfix it.\n\nBasically, Fedora tries hard to use system libraries rather than\nhaving applications include their own local copies.  (I recall some\nzlib vulnerabilities years back that required way too many packages to\nbe rebuilt, since they each included their own copy of zlib.)\n\nObviously, since git is not intended to be used as a library, this\ndoesn't exactly match that situation.  But cgit is using git as a\nlibrary at the moment and if we could find a way to only have one copy\nof the git sources to maintain, that'd be ideal from a distribution /\npackaging perspective.  I do understand that it might not be as ideal\nfrom either git or cgit developer / maintainer perspective, so the\nconsideration you're giving the issue is very much appreciated.\n\n-- \nTodd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nI never vote for anyone; I always vote against.\n    -- W.C. Fields\n\n"}]}