Package Details: canto-curses-git 0.9.7-1

Git Clone URL: https://aur.archlinux.org/canto-curses-git.git (read-only)
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=0.9.7
Submitter: TrialnError
Maintainer: TrialnError
Last Packager: TrialnError
Votes: 18
Popularity: 0.101069
First Submitted: 2012-07-26 11:41
Last Updated: 2016-06-01 19:31

Dependencies (5)

Required by (0)

Sources (1)

Latest Comments

ewancoder commented on 2015-08-07 16:05

Great. By the way, I have implemented one-by-one aur packages automatic installation, so the user would just have to type all the packages in the order he wishes it to be installed. Originally I implemented this approach because sometimes installation breaks (wrong PKGBUILD, wrong SHA), and then you have to manually install needed packages on the second TTY or execute installation of the whole software pack again (you can repeat any failed command). Now there's separate array for AUR packages which installs consecutively in the order it defined.

TrialnError commented on 2015-08-05 20:11

Jeah. For one case a drawback must be taken. And mixup should be a lesser case than stable -> stable, or git -> git. And hopefully not done via an install script :D
Cannot be handled otherwise for now.

ewancoder commented on 2015-08-05 19:54

Well, I tested latest changes. Everything works flawlessly with git versions.

But when you try to install "canto-curses-git canto-daemon" in one line, yaourt seem to installing first canto-next-git, then throw dependency error and exit.

One more word: if you install just like "yaourt -S canto-curses-git canto-daemon", yaourt graciously asks "canto-next-git and canto-daemon are in conflict. Remove canto-next-git?" and installs everything even with the stable daemon.

But I use '--noconfirm' option (especially in the script, because it is totally automatic), so the dependency error arose.

Anyway, in my case everything is perfect now. But anyone who uses canto-curses-git with the stable canto-daemon and tries to install them in one line, will be in trouble :)

TrialnError commented on 2015-08-05 16:13

No, it was right that way. Wanted to know if they would fall back to provides entries.
As this is not the case I will upload following change soon
* Stable package provides git-package but with a lower version
* canto-curses-git gets canto-next-git as dep
* canto-next-git still provides stable package.

With this it should still be possible to mix the packages (the way I want) and yaourt should get it right (the way you want)

ewancoder commented on 2015-08-05 16:07

There is currently NO canto-next package in old aur, only canto-curses, canto-curses-git and canto-next-git, so it throws

```error: target not found: canto-next>=0.9.1```

But if you change "canto-next>=0.9.1" to "canto-next-git>=0.9.1" in pkgbuild, it compiles successfully (which is kind of obvious because we explicitely say "install the GIT version").

So, I guess for testing there should be canto-next package at the old aur repository which were (accidentally?) removed.

TrialnError commented on 2015-08-05 08:41

Ok, I uploaded those changes to old AUR. Let's hope those work.
Now it's just the same with java-runtime or libgl, where one can choose what package he wants (if they reside in the repos at least)

ewancoder commented on 2015-08-05 03:49

You can change url to whatever you like. I personally changed it to aur4 until 8 august. So If you upload it to old aur "for testing" or to whatever else url, I can test it in yaourt.

TrialnError commented on 2015-08-04 21:04

No, not really.

From where does it download the PKGBUILDs? From the AUR or AUR4 address?. If the first it could be used as a testbed. Or is it chooseable from which AUR?

ewancoder commented on 2015-08-04 17:52

I could not find out how to tell yaourt to install packages from local pkgbuilds, maybe you can help with that.

TrialnError commented on 2015-08-04 11:15

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

All comments