Figure out package names of dependencies for various distributions

[karlch]

The install part of the documentation includes the required package names of the dependencies for different distributions. This should be done for:

• archlinux
• ubuntu / debian
• fedora
• ...

[sanjayankur31]

We have the vimiv package for Fedora but that uses the old code base. Is vimiv-qt ready for inclusion (mature enough for distribution to users)? If yes, would you prefer that I replace vimiv with this new code base, or should I package vimiv-qt as a new package? Since the binary remains vimiv, we can't carry both---they'll conflict. If I add vimiv-qt as a new package, it'll have to "obsolete" the one we have now.

[sanjayankur31]

Since the versions of vimiv-qt is currently 0.2.0, this cannot be considered an upgrade to vimiv whose latest version is 0.9.0 (0.9.0 > 0.2.0 in semver). So at least in Fedora, we'll have to package vimiv-qt as a new package and obsolete vimiv for the upgrade path to work correctly.

[karlch]

This actually concerns the names of the required software dependencies to run vimiv, e.g. pyqt5-common for archlinux to simplify installation using the Makefile (see here). I was hoping to release about one new minor version a month with the qt version from now on and then replace the gtk version with version 0.10.0 to have enough time to stabilize the software. Still unsure what I will do with the naming of the github repositories though, as this should then no longer be called vimiv-qt. Any opinions from a packager's point of view?

[sanjayankur31]

Ah, I'll be able to help with the dep names once I've been able to package the qt port up correctly.

If the idea is to only have one repository, the qt development should ideally be done in a qt or so branch back in the other repo (the gtk bits can be relegated to a gtk branch), with it being merged into master periodically---the versions would also then increase from 0.9.0 which was the last version of the gtk source---that signifies that the software is the same, even if it is undergoing heavy refactoring. Merging the two repos will not be trivial (if possible?)---the git trees have diverged drastically. I guess you could delete the old repo and rename this one if you really wanted to.

The simplest way would probably be to just use this now and leave it as vimiv-qt. I don't think that affects the tool too much. It probably makes it clear that this uses Qt, which is a good thing for users to know?

[karlch]

I would certainly keep the two repositories as both have their value in some way, but the Qt version should become the "default" at some point. Hopefully with the 0.10 minor release here. You are probably right that keeping it as vimiv-qt would make sense, in that way I could also already start uploading packages to the AUR and possibly PyPI with the vimiv-qt name. My only worry is that the old repository is much more discoverable and will keep on being used even after 0.10, although it is deprecated.

[sanjayankur31]

I think simply adding a banner on the old website saying "This is deprecated/archived, please use vimiv-qt instead" should be OK. To discourage its use further, you can archive the github repo, and if necessary remove the documentation from there too?

[karlch]

Closing in favour of #686