You are not logged in.
Another case in point, is that sometimes people will want to remove deps + add --disable-xxx build-options for avoiding unwanted functionality, e.g. one of the example configs in customizepkg disables dbus-glib for a package etc. Or, to add deps and extra build-options for added functionality..
Thanks, that is the use case I was looking for. I haven't even thought that adding deps could be needed before reading this.
Anyway, since packer does let you edit the pkgbuild before install(or use customizepkg for that automatically), then I would defenetelly say that it is a design-fault if changed deps aren't respected, but that's just me...
The first step to fix packer would be to allow makepkg to handle binary dependencies directly, instead of doing it at the very beginning. That way, adding or removing a *binary* dependency would be taken into account. The only cases that would not be working at this point would be adding or removing dependencies that are in the AUR.
Jshon mainly suffers from being very young. While hacking on Packer, I had to add several features to Jshon. Usually this is a sign the lead dev did not think things through. And it is an odd way of handling json, but the most sane way in a script.
I played a little with Jshon yesterday, and although really fast it seems to me that it wasn't returning always consistent results. I'm not sure if is strictly related to jshon or to other part of the code I played with, as I've got an unstable line that might explain inconsistencies (I'll do further testing). However, I'd said that expac is the way to go unless bruenig doesn't want to add binary deps to packer.
Offline
I played a little with Jshon yesterday, and although really fast it seems to me that it wasn't returning always consistent results. I'm not sure if is strictly related to jshon or to other part of the code I played with, as I've got an unstable line that might explain inconsistencies (I'll do further testing). However, I'd said that expac is the way to go unless bruenig doesn't want to add binary deps to packer.
Not to threadjack, but I'll need to see proof. Please post a test case on https://bbs.archlinux.org/viewtopic.php?pid=892595. There is no way you are getting non-determinism from this piece of code, but I will change how Jshon works to make it more clear/intuitive.
Last edited by keenerd (2011-07-24 13:05:42)
Offline
I would like to know if it is normal to have to type my root pass twice when I use "packer -Syu" ? It seems this come from this line of code
sudo -v &>/dev/null && sudo -l "$@" &>/dev/null
as sudo -v ask me to input my pass.
Offline
I would like to know if it is normal to have to type my root pass twice when I use "packer -Syu" ? It seems this come from this line of code
sudo -v &>/dev/null && sudo -l "$@" &>/dev/null
as sudo -v ask me to input my pass.
Do you have something like
Defaults timestamp_timeout = 0
in your sudoers file?
Offline
Yes I do
Offline
that is saying not to cache the password... by default it's 5 minutes I think unless you set it to 0. So... two calls to sudo equals two password requests
Last edited by oliver (2011-07-25 16:34:01)
Offline
So I am stuck with typing two pass. Thanks for the explanation
Offline
you could get funky and add a rule to sudoers saying run "sudo -v" without a password. All that does is extend the cache timer which, if it's set to 0, is useless anyway (unless I'm misinterpreting the meaning of -v)
Whether it's appropriate to modify your system wide sudoers rules for one app is another story. Maybe just remove the "sudo -v &>/dev/null && " from the script?
Last edited by oliver (2011-07-25 20:14:45)
Offline
I'm in no way in any position of saying what should, or shouldn't be included into packer, but personally, then the reason I really like this utility so much, is that it's a simple fast and small bash script, and the rest of the deps are always on a system(maybe not curl, but it's a dep of git, which many aur packages are using anyway, so fine by me)...
So, as a minimalistic purist I tend to only include the apps that I actually need and use, and so I wouldn't really be happy about also needing jshon and expac additionally for this little bash script, to maybe gain 0.5 secs or something at most, but that's just me and again, simply just my humble opinion
Offline
Just wanted to let you guys know that I made an 'Issues' report on the packer github repo, about changed deps not being respected, either through 'edit pkgbuild' or customizepkg, and he replied that if anybody was up for the challenge of incorporating this, and it worked good, then he had no problems with incorporating it...
Just a heads-up...
I myself am not going to do it, since I came to the conclusion that since I just use 2 aur packages currently, and where one of them is packer, then instead of using an aur helper, I will just instead use a simple bash function e.g.
aurget() {
for pkg in "$@"; do
curl -sk "https://aur.archlinux.org/packages/$pkg/$pkg.tar.gz" | tar xz
cd $pkg
makepkg -si --noconfirm
cd - >/dev/null
rm -rf $pkg
done
}
And use 'aurget $(pacman -Qmq)' to upgrade, and 'aurget pkg' to install...
Last edited by mhertz (2011-11-25 01:51:32)
Offline
With great reservations I've removed Expac from my branch. Somehow I was able to keep color support, but only with sed 'c/th/ulh/u' tricks and moderate loss of sanity.
Offline
Does packer support building from abs too?
K.i.s.s. <3
Offline
Can you please implement Pacman's --needed switch, it's very useful when installing a large amount of packages and one of them fails (otherwise you end up rebuilding/reinstalling all the packages that had successfully installed unless you go and check every package individually which is a major PITA).
Offline
Still not getting any color in pacman's output when using packer. If I install pacman-color and run it, color works. If I then run packer -Syu (for instance), no color. Doesnt matter whether pacman-color is installed or not. Installed the latest git version- still nothing.
Replaced cower and paktahn for me though.. fast and works well. Also, more consistent with pacman in terms of output as opposed to other AUR helpers.
Offline
Pacman-color has been the cause of a lot of trouble, particularly whenever there is a pacman upgrade. So support for pacman-color was removed.
Packer still has color output for -S, -Ss, -Si, and interactive/quiet modes. Installing a package won't be colorized, since that goes through pacman. Similarly -Syua is half done in pacman and half done in packer, colorizing the whole thing would be tricky.
Offline
Pacman-color has been the cause of a lot of trouble, particularly whenever there is a pacman upgrade. So support for pacman-color was removed.
Packer still has color output for -S, -Ss, -Si, and interactive/quiet modes. Installing a package won't be colorized, since that goes through pacman. Similarly -Syua is half done in pacman and half done in packer, colorizing the whole thing would be tricky.
Ahh, I see. I saw alot of mention of packer supporting color and couldnt seem to get it working, so I thought id mention it... Nice wrapper though- very simple. A good balance between yaourt/paktahn and cower..
Offline
it'd be nice if packer shows download count like yaourt
When you live for a strong purpose, then hard work isn't an option. It's a necessity. - Steve Pavlina
dotFiles
Offline
Hi,
I did not read all this thread because it's huge and maybe my suggestion was already discussed...
But here we go: why not change the _gitroot/_gitname variables in the pkgbuild to _gitbase/_gitrepo (for example). Using other variable names will avoid that odd behavior that makes the package version different from the version explicited in the pkgbuild.
I'm using this _solution_ in one of my pkgbuilds and everything looks ok.
Thanks.
Offline
This utility support depends from AUR?
Offline
This utility support depends from AUR?
Yes. It has some hiccups with longer dependency chains, but it works for most of the time.
Offline
For some reason packer wanted to build powerpill before building and installing perl-xyne-common and other dependencies, so powerpill build failed. Re-running the installation installed powerpill and bauerbill fine, because their dependencies were already installed this time.
...
Edit powerpill PKGBUILD with $EDITOR? [Y/n] n
==> Making package: powerpill 2011.03.10.1-1 (czw, 8 wrz 2011, 17:38:05 CEST)
==> Checking runtime dependencies...
==> Missing Dependencies:
-> perl-xyne-arch>=1.0
-> perl-xyne-common
==> Checking buildtime dependencies...
==> ERROR: Could not resolve all dependencies.
The build failed.
Edit perl-xyne-common PKGBUILD with $EDITOR? [Y/n] n
==> Making package: perl-xyne-common 2011.03.10.2-1 (czw, 8 wrz 2011, 17:38:15 CEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving Sources...
-> Downloading perl-xyne-common-2011.03.10.2.tar.gz...
...
Dependencies for `bauerbill' are not met, not building...
Offline
For some packages I get the error message that the source cannot be extracted. Here is one example.
[robert@thinkpad ~]$ packer -S jdownloader
Aur Targets (2): java-runtime jdownloader
Proceed with installation? [Y/n]
tar: This does not look like a tar archive
gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error is not recoverable: exiting now
/usr/bin/packer: line 271: cd: java-runtime: No such file or directory
No PKGBUILD found in directory.
What's the reason for this error? I do not think that there is a problem with the PKGBUILD itself.
Regards
Last edited by orschiro (2011-09-17 01:12:12)
Offline
I think java-runtime is / was a virtual package of sorts.
jre6 provides java-runtime=6 which conflicts with java-runtime.
jre7 provides java-runtime=7 which conflicts with java-runtime.
https://aur.archlinux.org/packages.php?ID=50317 provides both 'java-runtime' and 'java-environment'.
Offline
I've stumbled on a nice problem. I have sabnzbd installed which depends on pyhton-yenc (in community). The new version of sabnzbd depends on python2-yenc (in AUR), which conflicts with python-yenc. However, I cannot update sabnzbd, because when packer tries to install python2-yenc and remove python-yenc, I get an error saying that sabnzbd requires python-yenc.
This sounds like a horrible problem to solve. Good luck!
Offline
I've stumbled on a nice problem. I have sabnzbd installed which depends on pyhton-yenc (in community). The new version of sabnzbd depends on python2-yenc (in AUR), which conflicts with python-yenc. However, I cannot update sabnzbd, because when packer tries to install python2-yenc and remove python-yenc, I get an error saying that sabnzbd requires python-yenc.
Have you tried removing pyhton-yenc manually with '-Rdd'?
Offline