Package Details: canto-curses-git 0.9.9.r3.g13648d5-2

Git Clone URL: https://aur.archlinux.org/canto-curses-git.git (read-only, click to copy)
Package Base: canto-curses-git
Description: ncurses user interface for canto-daemon/canto-next. Git version
Upstream URL: http://codezen.org/canto-ng/
Keywords: atom rss
Licenses: GPL
Conflicts: canto-curses
Provides: canto-curses
Submitter: TrialnError
Maintainer: TrialnError
Last Packager: TrialnError
Votes: 18
Popularity: 0.000000
First Submitted: 2012-07-26 11:41 (UTC)
Last Updated: 2024-03-30 23:23 (UTC)

Latest Comments

« First ‹ Previous 1 2

TrialnError commented on 2015-08-04 11:15 (UTC)

I see. Should this occur with more packages? Probably not. This is more or less an edge case as in most cases -git PKGBUILDs will point to -git ones (despite the fact if it really makes sense or not). Currently I think the error occurs because pkgname and provides are the same. As I wanted to mimic scenarios like with java-runtime (choice) this should be sligthly changed then. I will later test what happens if set the provides line to canto-next or canto-engine and change the dep to the provides name. My intended behaviour should still work and theoretical yaourt could behave different. Maybe you could test that too? I made some quick adjustments which you can find here. https://gist.github.com/Narrat/8b5eddf94003ed4763d9 Personally I can this test only later, when I'm home and can get my hands on my systems

ewancoder commented on 2015-08-04 07:40 (UTC)

Well, updating works fine, it's just "first time install" issue. For now I am installing canto-next-git and only then canto-curses-git (for example yaourt -S canto-next-git && yaourt -S canto-curses-git), this works fine. I just thought it might be worth changing the dependency. My initial issue is that I am writing my own arch linux installation script which is installing all the software in the process (based on pre-defined string). Currently you have multiple strings to install "consecutively", but if you choose to install all software at once, canto-next-git will throw an error. This is the one and only package (among many official/aur packages that I use) which behaves this way. So when another user will try to use my script and set "canto-next-git canto-curses-git" in one line, he will get an error. Are there examples of the same dependency politics for other AUR packages? Should I invest into reworking/improving my script for dependency checking?

TrialnError commented on 2015-08-03 23:07 (UTC)

Still yaourt doesn't seem to offer to replace the current installed package like pacman can do, if you install a conflicting package. Looks like a missing feature. With this setup like it is now, the users have the choice. They can install the git versions or not and mix it. Why would such a setup be needed? For example if the curses interface got problems as I have reported in the past. Nothing to do with the engine, just with the frontend. No need to use a git based engine. Of course this setup will produce problems if there are breaking changes but people should be aware if they're doing that (mixing it). For the case to prevent unaware mixing are the optdepends I set in the engine packages. Wrong doing, but they point the users to the counterpart. I just see the problem, where yaourt doesn't offer a simple oneliner on first install, because it doesn't offer to remove conflicting packages. And later? What happens when updating (I assume this can be invoked without a pkgrel/pkgver bump)? The official way of installing those packages works and that is just of my concern. People will look up what is here. They got a offer for four canto packages. Two engines, two frontends, one stable, one git. Regular users will go for the stable ones, building and installing it. Devs and people that like it really fresh go for -git and -git. Again building and installing works fine. Now the case where engine or frontend has a problem, which gets reported and fixed upstream. They can switch one to the -git thing without adjusting the pkgbuild. My reasoning, but maybe I missed a compelling reason. But not the one "-git must depend on -git".

ewancoder commented on 2015-08-03 17:51 (UTC)

Yaourt seems to install packages alphabetically, so canto-curses-git installed before canto-next-git, and canto-next-git throws depencendy error. One more reason to change dependency to canto-next-GIT is because most users will use canto-curses with canto-next, and canto-curses-git with canto-next-git. In many cases, canto-curses-git is updated with canto-next-git and requires new canto-next-git to work as intended. Why would you want to use canto-curses-git (which may rely on canto-next-git) with (old) canto-next daemon?

TrialnError commented on 2015-08-02 21:38 (UTC)

Most of the time stable daemon can be used with the git curses interface, and around so I set the deps like they are. And as the c-next-git PKGBUILD has the provides line set it is no problem installing it via makepkg+pacman. If yaourt doesn't check on the pkgname and provides entries if there is more than one argument given and just sort and work the entries down. Well. I'm still not convinced to change it and personal adjustments are possible

ewancoder commented on 2015-08-01 19:13 (UTC)

Why is canto-curses-git dependency is canto-next and not canto-next-git? When you try to install "canto-next-git canto-curses-git" it throws a dependency error because yaourt installs first canto-curses-git with it's depencendy "canto-next", and only then "canto-next-git" which is conflicting with "canto-next" and do not install. It is more logical to have canto-next<->canto-curses dependency, as well as canto-curses-git<->canto-next-GIT dependency.

TrialnError commented on 2014-09-12 19:25 (UTC)

The 0.9 release of canto-{curses, daemon} is near. In a blogentry jmiller made it clear, that canto-0.7 shouldn't be used anymore.[0] In addition the old canto homepage is gone, Information too. Bug reports are piling up and won't get fixed. So it's advised to switch (if not already done) to the 0.8 branch. Lot of changes. Read older blog posts for more information. Here the links for the new versions.[1][2] Relativley soon I will file a merge request and this PKGBuild will be gone. _______ [0] http://codezen.org/canto-ng/2014/09/11/sept-11th-2014/ [1] https://aur.archlinux.org/packages/canto-curses-git/ [2] https://aur.archlinux.org/packages/canto-next-git/

« First ‹ Previous 1 2