Re: Git Packaging Round 2: SHOULD Not or MUSt NOT Github
On Sat, Sep 14, 2019 at 12:16:43PM +0200, Adam Borowski wrote:
> On Sat, Sep 14, 2019 at 09:37:00AM +0530, Pirate Praveen wrote:
> > I will also support such a GR. I started packaging gitlab so we don't
> > have to compromise on ease of use compared to github.
>
> And, despite a massive amount of efforts from you and others, packaged
> gitlab is not fit for Salsa use. It hasn't also ever been in a stable
> release of Debian, despite being around since a year before Stretch's
> freeze.
And even if there is a package, how do you plan to ask DSA to use it and
run this service themselves? Hint, as we told a hundred times before:
Salsa runs on a DSA controlled machine, _without_ root.
> Looking at the number and complexity of packages needed solely for gitlab,
> I'd say that they'll collapse the moment you get busy with other tasks.
> This doesn't say anything good about Gitlab's design.
Let's compare it with other solutions:
## GitLab unicorn application
* Ruby gems included directly: 199
* Ruby gems included recursive: 333
* node.js modules included directly: 113
* node.js modules included recursive: 1760
Of the Ruby gems, 6 are from GitLab itself and are maintained separate.
With the listed software available everything is built from source.
## gitea
* Go modules included: 122
* node.js dependent projects vendored: 21
I assume the vendored stuff can be rebuild using this:
* node.js modules included directly: 8
* node.js modules included recursive: 516
## pagure
* Python modules required directly: 70
* node.js dependent projects vendored: 16
Regards,
Bastian
--
Klingon phaser attack from front!!!!!
100% Damage to life support!!!!
Reply to: