Page MenuHomePhabricator

Arcanist isn't packaged in Fedora, Debian, or Ubuntu
Closed, ResolvedPublic

Description

Arcanist isn't packaged in Fedora, Debian, or Ubuntu. The installation instructions at https://secure.phabricator.com/book/phabricator/article/arcanist/ are very "manual", and there is no indication that there is any QA that Arcanist runs on those distributions and that it will do so after running "arc upgrade".

It needs to be properly packaged in a working state with defined dependencies.

There is an upstream task (https://secure.phabricator.com/T4200), but it's stated to be low-priority, for various reasons including upstream's lack of experience with packaging and Phabricator's rate of change.

Details

Reference
fl224

Event Timeline

flimport raised the priority of this task from to Medium.Sep 12 2014, 1:31 AM
flimport set Reference to fl224.

qgil wrote on 2014-04-26 17:22:16 (UTC)

To be more precise, Arcanist is not packaged in any OS. You git clone and then configure the paths. I wonder how big of a problem this is for an audience that is going to use Git in 100% of cases. In exchange of this, updating is simple, and you don't need to depend on new versions of packages.

Looking at "Installing Arcanist for a Team, it looks like in some cases (e.g. all WMF employees) could have a very simple setup. It needs to be seen in practice, though.

It would be useful to get feedback from Windows users setting up their environment for Gerrit vs setting it for Phabricator, since this has been a clear pain point in our current setup.

mattflaschen wrote on 2014-05-05 21:01:03 (UTC)

I filed a separate one for Windows, T280: [EPIC] Code Deploy Dashboard.

However, I think packaging it for GNU/Linux distributions is also reasonable. People have pointed out that not everyone (even in the MediaWiki community) already has or needs PHP, so an installer that simply handled this (installing command-line PHP automatically if needed) would be preferred.

scfc wrote on 2014-05-05 21:38:51 (UTC)

I wonder how big of a problem this is for an audience that is going to use Git in 100% of cases.

The problem isn't technical. If I had an unstoppable inflow of money and noone cared about the output, having dozens of developers spend time on installing/updating/debugging sounds like a good plan to burn some of it. As a volunteer my time is more scarce, so I neither write my own distribution nor my own encyclopedia.

People have pointed out that not everyone (even in the MediaWiki community) already has or needs PHP, so an installer that simply handled this (installing command-line PHP automatically if needed) would be preferred.

No, the package just needs to state which PHP version is required. Installing that is left to the distribution which has a much better track record of that.

mattflaschen wrote on 2014-05-05 22:49:32 (UTC)

scfc:

No, the package just needs to state which PHP version is required. Installing that is left to the distribution which has a much better track record of that.

Sorry, I should have been clearer. I was thinking only of the Windows installer with regards to installing PHP. And even for that, it should simply bundle (or download on demand) the installer from http://windows.php.net/ .

For GNU/Linux, etc (i.e. OSes with package managers). it should just add a dependency on PHP.

richard wrote on 2014-07-17 15:31:02 (UTC)

I'm working on the debian/ubuntu packaging. See https://github.com/lenios/phabricator. The source package builds binary packages for arcanist, libphutil and phabricator. All packages should work properly. The packages are in the debian NEW queue, and hopefully soon available.

Qgil lowered the priority of this task from Medium to Lowest.Oct 9 2014, 11:08 PM

This is work to be organized upstream. I don't see Wikimedia creating and maintaining these packages.

greg added a subscriber: greg.Sep 3 2015, 6:49 PM

System packages probably aren't the way to go anyway for arcanist. Arcanist uses the Conduit API in Phabricator and that can change (and break) so best practice is to use whatever version of Arcanist is associated with the version of Phabricator you're interacting with.

This (the above, that syncing) can be mostly automated and guided for our developers with how we tell them to setup their arcanist install. Essentially it's simply a git pull to somewhere in the user's path. That is all automatable through a setup script. The act of keeping things in sync could also be automated, or the user could simply run arc upgrade (which essentially just runs git pull on the right repos, see P1976).

But, for the record, arcanist (and Phabricator) are now packaged for Debian and Ubuntu. Not sure about Fedora.

I don't believe the lack of package for Fedora is a blocker for the Differential migration.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 3 2015, 6:49 PM
greg edited projects, added Differential; removed Gerrit-Migration.Sep 3 2015, 10:03 PM
greg set Security to None.

Put this in the Differential project instead of Gerrit-Migration because it is not a migration blocker but still a (very very very low priority) request/task.

greg closed this task as Resolved.Sep 4 2015, 2:45 AM
greg claimed this task.

That's actually good enough for me to considered this task resolved.

Using copr is basically the equivalent of downloading random .deb files from the internet. This bug is about being packaged *in* Fedora, not just *for* Fedora.

Qgil added a comment.Sep 4 2015, 6:41 AM

If this is not Resolved, then I would consider resolving it as Declined. We are not going to work on those packages ourselves, but also...

With Wikimedia Phabricator following upstream's master so close, chances are that git pull is going to be the most reliable way to have Arcanist up to date. With all our code contributors having Git enabled in their systems, it is also the simplest way to support them with documentation and advice.

In the strange case that this approach fails because Wikimedia Phabricator gets out of sync more often than desired, then probably the solution is to keep our own mirror of Arcanist in sync with our own installation. If we happen to get out of sync even after updating our instance almost every other week, we can expect the packages in the distros to get out of sync more frequently.

scfc added a comment.Sep 4 2015, 9:48 AM

I think that belittles the work distribution packagers do. If I install a package, someone has made sure that it works, and that it works with the distribution I am using. It will receive security fixes, and if I use it in a workflow, I don't have to fear that the semantics of arcanist --help will suddenly change to mean rm -Rf ~.

AFAIK, WMF has to employ several engineers just to keep the Phabricator server up to date and yet is surprised when for example it maxes out on database connections. I don't want to have to worry on my own about whether the tools I use to get work done actually work.

Qgil added a comment.Sep 4 2015, 9:59 AM

I guess distribution packagers will test Arcanist against the Phabricator snapshot they are shipping in the same distribution? If this is true, would we willing to rely in those packages (both Phabricator and Arcanist) instead of pulling directly from Phabricator master as we have been doing until now?

PS: anyway, this is not my area of expertise, so I think this is the last potentially useful contribution I can make to this discussion. :)

Please correct me if i'm wrong: For every installation of phabricator you need to use that specific arcanist, as there is no compatibility intended between any two versions. So if you use phabricator.wikimedia.org, secure.phabricator.com and phabcirator.kde.org then you need 3 different copies of arcanist. Each obtained from that specific installation. When we document arcanist usage for our workflow, we should remember to explicitly mention that using a packaged arcanist or an others version is not support because upstream explicitly disclaims that they have no compatible interfaces.

Pulling from a distribution instead of directly from upstream woun't help with that as one distribution usually has multiple versions and different distributions have different versions. Only upstream can create a backwards compatibility guarantee and ensure that they keep it.

In T133#1605471, @Qgil wrote:

With all our code contributors having Git enabled in their systems, it is also the simplest way to support them with documentation and advice.

I do not believe this is a true statement. I know there are people who use github's web UI + gerrit-patch-uploader to contribute, without ever having to deal with git. But that's probably a separate bug.

greg added a subscriber: mmodell.Sep 4 2015, 4:42 PM

Please correct me if i'm wrong: For every installation of phabricator you need to use that specific arcanist, as there is no compatibility intended between any two versions. So if you use phabricator.wikimedia.org, secure.phabricator.com and phabcirator.kde.org then you need 3 different copies of arcanist. Each obtained from that specific installation. When we document arcanist usage for our workflow, we should remember to explicitly mention that using a packaged arcanist or an others version is not support because upstream explicitly disclaims that they have no compatible interfaces.

This is my understanding, correct @mmodell?

Pulling from a distribution instead of directly from upstream woun't help with that as one distribution usually has multiple versions and different distributions have different versions. Only upstream can create a backwards compatibility guarantee and ensure that they keep it.

Right, which is why this task is rightly closed, I still believe.

We probably need to distribute arcanist ourself, and update our fork when we update phabricator, to keep the two in sync. We could use debian packaging infrastructure to build debs that are updated with our own version of the source. But distributing and updating arcanist is really pretty straightforward - just git clone from our fork of arcanist and then periodically run arc upgrade to stay up to date.

Now that upstream has implemented a stable branch, I expect broken api compatibility to be infrequent and minimally disruptive.

Restricted Application added a project: User-greg. · View Herald TranscriptSep 11 2015, 9:30 PM

I don't think creating debian packages for our version of arcanist is useful, except the chain of trust and integrity it provides. Instead I would suggest as alluded to in T613#1622313 to git tag --sign our version of the needed git repos and be done with it. Or get upstream to sign and use their tags as is.

greg moved this task from Backlog to Done on the User-greg board.Sep 24 2015, 11:37 PM
hashar added a subscriber: hashar.Jun 30 2016, 10:24 AM

We had arcanist / libphutil packaged via T137770

greg added a comment.Jun 30 2016, 3:57 PM

To be clear: it isn't in Debian itself, we just have Debian packages in our Wikimedia apt repo (initial use case was to enable aspects of CI integration with Differential).

See: https://www.mediawiki.org/wiki/Phabricator/Arcanist#Using_packages

Anyone is free to add that repo to their sources.list, of course, and install it that way. If you're on Debian and/or Ubuntu and don't like the git clone method, this is the next best thing (they'll be kept up to date and in sync with our Phabricator install for our own needs).