Package hamster-shell-extension in Linux distributions

[DirkHoffmann]

From #319 and elsewhere, the question arises, if it is possible to ship a gnome-shell-extension together with a matching hamster and gnome-shell combination for a given Linux distribution.

@elbenfreund and myself believe that gnome-shell is designed in a way that prevents system-wide installation, which is the basis of distribution packages. For me this is obvious from the fact that the installation needs to be made in $HOME/.local/share/gnome-shell/extensions/.
@benjaoming and @mwilck seem to have a different point of view. Correct?

[DirkHoffmann]

The answer seems to be here: https://help.gnome.org/admin/system-admin-guide/stable/extensions-enable.html.en
Is that what you had in mind, @benjaoming, @mwilck? Sorry for the noise in that case.

[mwilck]

@DirkHoffmann, that's exactly what I did for openSUSE - install under /usr/share/gnome-shell/extensions. I didn't go into automatic extension enablement, and I don't think I should as a distro maintainer. Enabling/Disabling extensions is currently handled via gnome-tweaks, and will be handled by a new, dedicated tool in the future.

That said, installing extensions this way is generally deprecated on openSUSE. I can't find the reference just now, but the general idea is that GNOME extensions should preferably be obtained from extensions.gnome.org. But there are exceptions from the rule, and hamster is one of them.

In general, installing GNOME extensions with the distro provides a better user experience when GNOME is updated. The back side of the coin is that this puts the burden on the distribution's maintainers and QA people. I guess that's the main reason for distributions to discourage shipping GNOME extensions as native packages - GNOME extensions are broken just too frequently, and the GNOME core developers don't seem to care about them at all.

Bottom line: the answer to your initial question is clearly YES. I propose to close this issue.

[benjaoming]

@DirkHoffmann Since yesterday, I quickly searched, and there are heaps of Gnome extensions packaged for Debian already, we can call them "system-wide" extensions. I used them for my analysis in #319

As such, they are signed by the package managers and will receive automatic updates through Debian/Ubuntu.

For that reason, I would clearly say YES, too. No problem in packaging it for Linux, and also a benefit for all the users.

If there are people in Debian who do not want further Gnome Extensions packaged, I would try to spend some time explaining them why this extensions (a bigger one with a larger community) isn't thriving in such a scenario. But I hope this isn't the case -- @mwilck if you find the reasoning somewhere, please don't mind that you share it here.

I'd also close this issue with a YES.

[mwilck]

-- @mwilck if you find the reasoning somewhere, please don't mind that you share it here.

I was talking about the reasoning against packaging extensions. My "exception" was obtained by simply filing a request in the openSUSE build service, and reviewers accepted it. The argument at the time was simple: there was no working extension available from extensions.gnome.org. Once we've settled issues here and e.g.o. is back up-to-date, I may (need to) reconsider.

[benjaoming]

Yes, I know that you were talking about the reasoning against it, so please don't mind if you share that if you come across it :)

[DirkHoffmann]

OK. Then you guys have some homework. 😁
Thank you.
Does it imply some code in this repo, or will everything be distro-specific and go into their repos?

[benjaoming]

I would like if projecthamster had a hamster-debian repository. This could collect the Debian community in one place and connect the maintenance of the Debian package to the rest of hamster.

[benjaoming]

It's not a blocker to get started -- me or @matthijskooijman can create a debian package repo and request transfer of ownership later.

[DirkHoffmann]

I would like if projecthamster had a hamster-debian repository. This could collect the Debian community in one place and connect the maintenance of the Debian package to the rest of hamster.

@elbenfreund, your call?

@benjaoming, as a quick-and-dirty hack, maybe you can create one under your github account, and it can be copied (cloned/forked) here later?

[matthijskooijman]

I would like if projecthamster had a hamster-debian repository. This could collect the Debian community in one place and connect the maintenance of the Debian package to the rest of hamster.

I had in mind to create a hamster-team on salsa.debian.org, which is a common place to keep Debian package, but creating a repo here might also work. It might need one repo per source package though, for clarity.

@benjaoming, as a quick-and-dirty hack, maybe you can create one under your github account, and it can be copied (cloned/forked) here later?

Indeed, l would say we should have a repo somewhere first, and then we can wonder about what the canonical location for it will be later?

[elbenfreund]

I am not familiar with the debian process, but I would have thought keeping the debian packaging stuff close to debian's infrastructure would be preferable.
If you want me to, I am more than happy to create an (temporary) repository under the hamster organization here to get things moving. Just give a call once you decide.

[elbenfreund]

I have created a repo in case you want to use it. I invited @matthijskooijman to the corresponding team and assigned the team full write access. If you want to use this infrastructure and want to be on the team, just give a a shout...

Happy hacking :)

[DirkHoffmann]

I think (hope) there will be some synergy possible among different distro-packaging processes(, although my experience with packaging DEB is close to zero). I imagine So the common things (file list, rules) should go into a common repository (which can be cloned into/from the distro repos, which will certainly have to exist at well) The distro people can certainly sort that out among themselves. We are lucky to have at least Debian, SuSE and Fedora expertise, as far as I can see. I believe that there will be more synergy between X-distro and Y-distro for the shell-extension and X-distro and Y-distro for the main package than between extension and core for X-distro for instance. (That's why I restricted the title of this issue to the *extension*.) Therefore I think it is too early to decide, if we need one repository per N distributions, one per M packages or N×M repos for each case. Just my 2 cents …

[hedayat]

Well, I don't think we need a repository per distro. And distro specific stuff will go into their on repos anyway (AFAIK, each distro has a source repo for its packages).

And IMHO, what is common for all distros should go into the main extension repo. No need for an extra repo.

Extension is no different from other projects, and I don't see any project has such repos. Also, even projects which do provide packaging stuff, that is usually not the one used in distro repositories!

[matthijskooijman]

And distro specific stuff will go into their on repos anyway (AFAIK, each distro has a source repo for its packages).

For Debian, it is customary to track the packaging in a VCS/git repo, but there is no mandated repo for this. Often these live on salsa.debian.org, but they can be anywhere the packager chooses.

Or maybe with "repo" you meant the package repository / package archive of Debian, e.g. where you can install packages from. This is a central place, but that tracks only complete (source and binary) package versions, it does not offer any VCS-like history features (so typically you'd have a VCS repo where you commit small changes, and once you're done with a version, you generate a changelog from git history and build a source package, which is then uploaded into the Debian archive).

And IMHO, what is common for all distros should go into the main extension repo.

I guess, yes. I suspect that whatever is common for all distros is useful for a manual install as well anyway.

Anyway, I looked a bit at how to track Debian packaging in git and considered whether we could:

• Use one repository for multiple packages (e.g. hamster and the extension). Using explicitly-named branch names, this might work, but probably gets confusing fast. Also, (upstream) git tags are all in a single namespace, so those might up conflicting. So this is probably not a good idea.
• Use on repository for multiple distros. This might work if the distros are related (e.g. use the same packagaging tools and version namespace, such as Debian and Ubuntu). Mixing completely unrelated distros (e.g. Debian and an RPM-based distro) could work by just using a distinct branches for each distro, but since this is typically done by completely different people, it probably just makes it more work to prevent interfering with each other (accidentally). There is also not really any gain, other than reducing the number of repos.

So, I think we would need one repo per package per distro, or more specifically, we would need one repo per package for Debian/Ubuntu that is not shared with other distros (somewhere, not neccesarily here).

Extension is no different from other projects, and I don't see any project has such repos. Also, even projects which do provide packaging stuff, that is usually not the one used in distro repositories!

As I said, a Debian packager can choose wherever to put their package repos, and usually they are not along upstream, but they might just as well be.

In this case, since I think the potential packagers are already involved here (rather than just being random distro packagers that pick up a release without much involvement upstream), it might make sense to just put the repos here. So unless anyone thinks having a handful of distro repositories is too confusing or messy, or otherwise a bad idea, I would like to use a hamster-debian-packaging and hamster-shell-extension-debian-packaging repo here (names are certainly up for suggestions).

[hedayat]

Thanks for your comments. I didn't know how debian works. hmm...from what I see, what I referred as 'repo' in Debian land is the FTP server you upload your package when ready.

Anyway, for Fedora it is really a git repo, with a branch for (almost) every fedora release. IMHO, it really doesn't make sense to keep such Fedora specific stuff somewhere else. There might be a not-so-much distro specific RPM spec file here, but I wonder if it'd be maintained well enough.

Anyway, I'm not against any decision. As I've said somewhere else, personally I'm not interested in packaging the extension as I think it doesn't provide much value over having it inside EGO; so I won't interfere with the decision here.

[mwilck]

For SUSE, packaging is tracked in the openSUSE build service. So we don't need any upstream packaging repos, either.

[matthijskooijman]

For Debian, I think I'll prefer to put things on salsa.debian.org, a bit closer to Debian than upstream. I pushed some work-in-progress for the main application to https://salsa.debian.org/projecthamster-team/hamster-time-tracker

[rhertzog]

I can help for the Debian packaging (and for the upload to Debian, I'm a DD), in fact I created a package today without noticing that you already had some packaging on salsa... I requested access, please grant me maintainer level access on the projecthamster team. I'm "hertzog" on salsa.debian.org.

[rhertzog]

FWIW, I uploaded to Debian a package for the shell extension too: https://salsa.debian.org/projecthamster-team/gnome-shell-extension-hamster

[pabs3]

The package has now reached Debian unstable.