Files integration on Manjaro

[Madis0]

Using GSConnect 15, GNOME 3.30.2, Manjaro 18.0.0.

In the "extra features" panel GSConnect claims I do not have the Files integration.

The wiki says that Arch(-like) systems require python-nautilus, which I can verify that I have installed. The GSConnect panel, however, attempts to install python2-nautilus and python2-gobject, which naturally results in a conflict. Why does it not find the right package?

In previous versions of GSConnect, the integration worked fine, maybe it is a matter of newer Nautilus and/or GNOME?

[andyholmes]

Why does it not find the right package?

All of the PackageKit integration was really just added as a convenience to resolve #162. No other extension I know of does this at all, they just throw errors or maybe show a notification.

Extensions were never meant to be as elaborate as GSConnect, so no one has ever bothered to do anything like this before (and probably shouldn't). Detecting the operating system (Linux, BSD) and distribution would just mean depending on more programs like lsb_release (not available on BSD). Currently we have to keep track of a half-dozen distributions, different package names, distributions that have packages with the same name but do different things and changes between releases.

In previous versions of GSConnect, the integration worked fine, maybe it is a matter of newer Nautilus and/or GNOME?

Before v13 we didn't support this at all, in v13 it didn't work on a few big distributions and there are certainly ones that still don't. Nothing has changed in Nautilus to affect this, and in fact the only distribution that always used the proper name for this package (nautilus-python) is Gentoo (and for the last few days Fedora 29, which now has conflicting packages, yay). Everyone else seems to have just "made up" their own name, probably to suit their own packaging guidelines.

This might be fixable with some more work and testing of PackageKit, but this isn't something I consider a high priority because it doesn't really have anything to do with GSConnect - it's really a package management issue. It's just that most extensions don't have packages built for them or any infrastructure for installing dependencies.

[ferdnyc]

It's just that most extensions don't have packages built for them or any infrastructure for installing dependencies.

And that's really the crux of the problem, here. Extensions.gnome.org was built to manage extension installation, but Shell extensions were always conceived as nothing more than little, self-contained bits of JavaScript. It has no concept of required libraries or other dependencies on the target system — even though many extensions do have additional requirements in order to function.

gnome-shell-extension-weather requires libgweather.so and GWeather-3.0.typelib installed, and just won't work without them. If it's packaged by a distro, they can set the dependencies accordingly (sometimes they're both provided by libgweather, others have a separate package for the .typelib file, like Ubuntu's gir1.2-gweather-3.0) — but if it's installed through e.g.o and you don't already have those packages installed, it'll just confusingly not function.

Meanwhile, gnome-shell-extension-pomodoro was one of the earliest Shell extensions (its ID at e.g.o is 53!), but the author pulled it after the extension was rewritten primarily as a vala library, since there's no way to install something like that via e.g.o and it's useless without it. So now Pomodoro can only be installed via distro packages or built from source, because the library and extension are built together. Like most shared libraries, libgnome-pomodoro.so has a dependency list a mile long. (See all the "BuildRequires".)

Expand for more yammering of no consequence (or "history" if you're being nice)...

Nothing even remotely that complex was really planned for, when e.g.o was first built. In fact the entire extension system was never envisioned to support anything remotely as complex as many extensions, including GSConnect. The original Gnome Shell developers figured extensions would be mostly used for minor tweaks to the Shell itself, things like arranging windows automatically or changing the color/size/placement of interface elements. (Which caused some early resistance to the entire extensions concept, as it conflicted with some developers' visions of a rigid, Apple-like design philosophy.) Early extensions were all just small, one-file snippets of JavaScript code. After enough of those were "distributed" by just posting them on the gnome-shell mailing list, [Giovanni Campagna proposed creating a git repo](https://mail.gnome.org/archives/gnome-shell-list/2011-January/msg00084.html) for them, which became [gnome-shell-extensions.git](https://gitlab.gnome.org/GNOME/gnome-shell-extensions). Not long after that, Jasper St. Pierre [started SweetTooth](https://wiki.gnome.org/action/recall/Projects/GnomeShell/SweetTooth?action=recall&rev=1), a project to build a centralized "app store" directory and installer for submitted extensions. The SweetTooth proposal prompted me to email Jasper directly (though we'd never had any contact before), because as I explained: > It's the first thing I've seen at gnome.org itself that's led me to think/believe, "This could actually make gnome-shell feel less like punishment!" ...SweetTooth eventually became e.g.o, and here we are today, still pushing the extension system far beyond what it was ever intended to support.

[Madis0]

Before v13 we didn't support this at all, in v13 it didn't work on a few big distributions and there are certainly ones that still don't. Nothing has changed in Nautilus to affect this, and in fact the only distribution that always used the proper name for this package ( nautilus-python ) is Gentoo (and for the last few days Fedora 29, which now has conflicting packages, yay). Everyone else seems to have just "made up" their own name, probably to suit their own packaging guidelines.

So basically PackageKit doesn't know Manjaro is similar to Arch and assumes different package names because of that?

[Madis0]

Well, this is odd. Today I noticed that the feature has somehow activated itself, and now I have two menu items for sending files in Nautilus, though the GSConnect interface still thinks it is disabled.

[andyholmes]

So basically PackageKit doesn't know Manjaro is similar to Arch and assumes different package names because of that?

No, it means Arch probably has two conflicting packages for Nautilus Python extensions. Most likely Python 2 and Python 3. PackageKit doesn't know what the difference is, it just knows python2-nautilus and python-nautilus are thingies about the Nautilus thingy and it's supposed to want them.

[andyholmes]

I'm going to mark this as a duplicate and join it with issue #325 since there's been some technical progress made in that thread. Feel free to take part there and add any additional details concerning the dependency UI and PackageKit situation.

duplicate of #325